Issue with mixed line endings

[dbanty]

If I squash a commit through the GitHub UI, for some reason it gives me a commit message with mixed line endings like:

"feat: did a thing\n\ncloses #1234\r\n\r\nBREAKING CHANGE: something broke"

However, if I parse that message via this library like:

#[test]
fn test_mixed_line_endings() {
    let commit =
        Commit::parse("feat: thing\n\ncloses #1234\r\n\r\nBREAKING CHANGE: something broke")
            .unwrap();
    assert_eq!(commit.breaking_description(), Some("something broke"));
}

It doesn't detect the breaking change. Looks like it continues parsing until the next \n and misses that footer. There's not much I can do to fix GitHub, so I'm hoping it's possible to fix it within this library.

[dbanty]

It seems from some debugging I might also be hitting a weird case where # is triggering the start of a footer? From my read of https://www.conventionalcommits.org/en/v1.0.0/ the body should keep going until there is a blank line, so there may need to be a tweak there? I've tried to tinker with the parser a bit but I'm finding the nom syntax very hard to understand 😅. I pretty much always have # in the summary, body, or both to reference GitHub issues.

Oddly, that body works fine when I only have \n and not \r\n (my workaround right now is to amend commits which resets the line endings).

[epage]

It seems from some debugging I might also be hitting a weird case where # is triggering the start of a footer? From my read of https://www.conventionalcommits.org/en/v1.0.0/ the body should keep going until there is a blank line, so there may need to be a tweak there?

\n\n between the summary and closes does mean there is a blank line and according to the spec, closes #1234 is a footer

One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a : or # separator, followed by a string value (this is inspired by the git trailer convention).

I'm digging into why its not matching the remaining output.

[epage]

Also, looks like its not just mixed line endings but windows line endings.

As a workaround until this is fixed, these can always be normalized in whatever tool is being used.

[epage]

v0.11.2 is released with this fix

[dbanty]

Awesome, thanks for the quick fix! I'm a bit confused still on the separation between body and footer but it doesn't actually matter for my purposes right now 😅.

[epage]

Since Closes #number tends to be metadata, filling a role similar to footers, Conventional Commit spec decided to extend git's footer syntax with support for them also being considered footers.

[dbanty]

Since Closes #number tends to be metadata, filling a role similar to footers, Conventional Commit spec decided to extend git's footer syntax with support for them also being considered footers.

Oh, cool, thanks for clarifying! And thanks again for the fix 😁