Is the Refs footer supposed to be missing a :? #132

New Issue

GiteaMirror · 2026-02-17T11:48:43-06:00

GiteaMirror commented

2026-02-17 11:48:43 -06:00

Originally created by @daotoad on GitHub (Sep 30, 2021).

The example in the main index.md showing a commit with a Refs footer (https://github.com/conventional-commits/conventionalcommits.org/blob/master/content/v1.0.0/index.md#commit-message-with-multi-paragraph-body-and-multiple-footers) shows no ':' delimiter.

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

Is that correct? Are there particular footers that are special? Or is this just a typo?

Originally created by @daotoad on GitHub (Sep 30, 2021). The example in the main index.md showing a commit with a Refs footer (https://github.com/conventional-commits/conventionalcommits.org/blob/master/content/v1.0.0/index.md#commit-message-with-multi-paragraph-body-and-multiple-footers) shows no ':' delimiter. ``` fix: correct minor typos in code see the issue for details on typos fixed. Reviewed-by: Z Refs #133 ``` Is that correct? Are there particular footers that are special? Or is this just a typo?

GiteaMirror closed this issue

2026-02-17 11:48:43 -06:00

GiteaMirror commented

2026-02-17 11:48:44 -06:00

@damianopetrungaro commented on GitHub (Oct 5, 2021):

Fixed @daotoad 😄 !

@damianopetrungaro commented on GitHub (Oct 5, 2021): Fixed @daotoad 😄 !

GiteaMirror commented

2026-02-17 11:48:45 -06:00

@runoncedev commented on GitHub (Jan 18, 2022):

Sorry to bring this up but the specifications states:

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

My interpretation is that a footer should either use one or the other, not both at the same time.

Good:

Refs #133

Bad:

Refs: #133

@runoncedev commented on GitHub (Jan 18, 2022): Sorry to bring this up but the [specifications](https://www.conventionalcommits.org/en/v1.0.0/#specification) states: > 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 :<space> or <space># separator, followed by a string value My interpretation is that a footer should either use one or the other, not both at the same time. Good: ``` Refs #133 ``` Bad: ``` Refs: #133 ```

GiteaMirror commented

2026-02-17 11:48:46 -06:00

@wtho commented on GitHub (Apr 7, 2022):

@damianopetrungaro I also understand either a : or # separator that it can omit the colon : if instead # is present.

Can you revert the change or, even better, add another example? I think e. g. Closes #012 is a more common example for
<token> #<value> than Refs.

@wtho commented on GitHub (Apr 7, 2022): @damianopetrungaro I also understand *either a : or # separator* that it can omit the colon `:` if instead ` #` is present. Can you revert the change or, even better, add another example? I think e. g. `Closes #012` is a more common example for `<token> #<value>` than `Refs`.

GiteaMirror commented

2026-02-17 11:48:47 -06:00

@LemmingAvalanche commented on GitHub (Mar 20, 2024):

The :<space> / <space># dichotomy comes from the effort to be optionally compatible with git trailers. And git-interpret-trailers(1) made the separator flexible (you can use %<space> for that matter) in order to be compatible with the already established at the time Fixes #98 ( or Fix?) GitHubism.

The way that this is handled in git(1) is that you can (1) configure the set of legal separators and (2) tell which separator is used for a specific trailer. (by default : is the only legal separator.) For example

# only these two
git config trailer.separators ":#"
# `#` for this trailer
git config trailer.fixes.key "Fixes #"

I don’t know how this tool handles it in general but I only use :<space> in order to be compatible with git(1).

@LemmingAvalanche commented on GitHub (Mar 20, 2024): The `:<space>` / `<space>#` dichotomy comes from the [effort](https://github.com/conventional-commits/conventionalcommits.org/issues/179#issue-481856441) to be optionally compatible with [git trailers](https://git-scm.com/docs/git-interpret-trailers). And git-interpret-trailers(1) made the separator flexible (you can use `%<space>` for that matter) in order to be compatible with the already established at the time `Fixes #98` ( or `Fix`?) GitHubism. The way that this is handled in git(1) is that you can (1) configure the set of legal separators and (2) tell which separator is used for a specific trailer. (_by default `:` is the only legal separator._) For example ``` # only these two git config trailer.separators ":#" # `#` for this trailer git config trailer.fixes.key "Fixes #" ``` I don’t know how this tool handles it in general but I only use `:<space>` in order to be compatible with git(1).

GiteaMirror referenced this issue

2026-02-17 11:58:22 -06:00

[PR #132] [MERGED] style: allow footer reference to be more generic regarding the type #307

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#132