fix: footer seperator : requires space

[jan-ferdinand]

According to the conventional commits specification v1.0.0 §8: “Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value.”

Previously, the separator : was accepted. Now, lines missing a space between the colon and the following string value are not parsed as footers.

[epage]

It looks like there is an inconsistency between the written spec and the BNF spec, see https://github.com/conventional-commits/parser?tab=readme-ov-file#the-grammar

Unfortunately, it seems the grammar has been going unmaintained, maybe even the full spec (most changes seem to be in translations)

Note: Git also requires a space for trailers, see https://git-scm.com/docs/git-interpret-trailers. I had opened conventional-commits/parser#41 about some other inconsistencies.

[jan-ferdinand]

Fair; I had admitedly not looked that far. I'll close this PR given you're already aware of the inconsistency and are actively pursuing betterment. 😊

[epage]

I'd recommend at least opening an issue against the grammar (my open issue is related to footers/trailers but doesn't cover this part).

[LemmingAvalanche]

@epage

Note: Git also requires a space for trailers, see https://git-scm.com/docs/git-interpret-trailers. I had opened conventional-commits/parser#41 about some other inconsistencies.

I don’t think it does

# message.txt
title
    
Key:valu

git interpret-trailers --only-trailers message.txt
Key: valu

Spaces after a trailer seem to be trimmed. And then the tool adds :<space> when outputting.

The man page also doesn’t seem to document it as a requirement.

[jan-ferdinand]

I don’t think it does

I think you're right, git does not require a space between the separator and the value. The relevant section seems to be:

When reading trailers, there can be no whitespace before or inside the <key>, but any number of regular space and tab characters are allowed between the <key> and the separator. There can be whitespaces before, inside or after the <value>.

Source as linked by @epage, emphasis mine.