github-starred/conventionalcommits.org
2
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2026-03-22 12:44:37 -05:00
Code Issues 153 Packages Projects Releases Wiki Activity

Are footers key/value pairs? #71

New Issue
Closed
opened 2026-02-17 11:42:19 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-02-17 11:42:19 -06:00
Owner
Copy Link

Originally created by @epage on GitHub (Jul 26, 2019).

I'm used to footers being key/value pairs:

  • BREAKING CHANGE: what changed
  • Co-Authored-By: some name

In reading an example of the web page:

fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

I'm trying to figure out if close issue #12 is being treated as a footer or another paragraph in the body.

Originally created by @epage on GitHub (Jul 26, 2019). I'm used to footers being key/value pairs: - `BREAKING CHANGE: what changed` - `Co-Authored-By: some name` In reading an example of the web page: ``` fix: correct minor typos in code see the issue for details on the typos fixed closes issue #12 ``` I'm trying to figure out if `close issue #12` is being treated as a footer or another paragraph in the body.
GiteaMirror commented 2026-02-17 11:42:20 -06:00
Author
Owner
Copy Link

@epage commented on GitHub (Jul 26, 2019):

Key/value pairs are helpful for

  • Detecting the footer (if all lines have ":" then it probably is the footer)
  • Parsing the content
@epage commented on GitHub (Jul 26, 2019): Key/value pairs are helpful for - Detecting the footer (if all lines have ":" then it probably is the footer) - Parsing the content
GiteaMirror commented 2026-02-17 11:42:21 -06:00
Author
Owner
Copy Link

@damianopetrungaro commented on GitHub (Jul 26, 2019):

They are not, but you can use them if you prefer to.
There are no strict rules about the format of the footer.

@damianopetrungaro commented on GitHub (Jul 26, 2019): They are not, but you can use them if you prefer to. There are no strict rules about the format of the footer.
GiteaMirror commented 2026-02-17 11:42:22 -06:00
Author
Owner
Copy Link

@bcoe commented on GitHub (Jul 29, 2019):

common footers I've seen are:

BREAKING CHANGE: foo
Fixes #20
Reviewer: bcoe

For starters, I think it would be good to update the spec to reflect the spec to reflect the fact that BREAKING CHANGE can fall in the footer; It might also be worth adding a note in the FAQ about what makes a good footer.

I think this would begin to address https://github.com/conventional-commits/conventionalcommits.org/issues/170, if you want a multi-paragraph body, but don't want that to be the same as your BREAKING CHANGE, put BREAKING CHANGE in footer. We could then mention in the spec that multi paragraph commit bodies should be spaced in, not separated by two newlines.

@bcoe commented on GitHub (Jul 29, 2019): common footers I've seen are: ``` BREAKING CHANGE: foo Fixes #20 Reviewer: bcoe ``` For starters, I think it would be good to update the spec to reflect the spec to reflect the fact that BREAKING CHANGE can fall in the footer; It might also be worth adding a note in the FAQ about what makes a good footer. I think this would begin to address https://github.com/conventional-commits/conventionalcommits.org/issues/170, if you want a multi-paragraph body, but don't want that to be the same as your BREAKING CHANGE, put BREAKING CHANGE in footer. We could then mention in the spec that multi paragraph commit bodies should be spaced in, not separated by two newlines.
GiteaMirror commented 2026-02-17 11:42:23 -06:00
Author
Owner
Copy Link

@epage commented on GitHub (Jul 29, 2019):

common footers I've seen are:

Github has native support for Co-Authored-By

Linux also has a lot of footers that are probably of interest to the wider git community

For starters, I think it would be good to update the spec to reflect the spec to reflect the fact that BREAKING CHANGE can fall in the footer; It might also be worth adding a note in the FAQ about what makes a good footer.

The spec does already talk about BREAKING CHANGE being in the footer

BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.

Breaking changes MUST be indicated at the very beginning of the body section, or at the beginning of a line in the footer section. A breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon and a space.

A ! MAY be appended prior to the : in the type/scope prefix, to further draw attention to breaking changes. BREAKING CHANGE: description MUST also be included in the body or footer, along with the ! in the prefix.

@epage commented on GitHub (Jul 29, 2019): > common footers I've seen are: Github has native support for [Co-Authored-By](https://help.github.com/en/articles/creating-a-commit-with-multiple-authors) Linux also has [a lot of footers](https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes) that are probably of interest to the wider git community > For starters, I think it would be good to update the spec to reflect the spec to reflect the fact that BREAKING CHANGE can fall in the footer; It might also be worth adding a note in the FAQ about what makes a good footer. The spec does already talk about BREAKING CHANGE being in the footer > BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type. > Breaking changes MUST be indicated at the very beginning of the body section, or at the beginning of a line in the footer section. A breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon and a space. > A ! MAY be appended prior to the : in the type/scope prefix, to further draw attention to breaking changes. BREAKING CHANGE: description MUST also be included in the body or footer, along with the ! in the prefix.
GiteaMirror commented 2026-02-17 11:42:24 -06:00
Author
Owner
Copy Link

@bcoe commented on GitHub (Jul 29, 2019):

@epage oh great, I wasn't sure that we had called that out (was going off memory).

Any ways, I don't think we should start legislating valid footers but I do think there's value in a note in the FAQ; "What makes a good footer", would happily take help writing this up.

@bcoe commented on GitHub (Jul 29, 2019): @epage oh great, I wasn't sure that we had called that out (was going off memory). Any ways, I don't think we should start legislating valid footers *but* I do think there's value in a note in the FAQ; "What makes a good footer", would happily take help writing this up.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
discussion
enhancement
greenkeeper
help wanted
meeting-agenda
operations
process
pull-request
Mirrored from GitHub Pull Request
 question
suggestion
support
triaged
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#71
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?