ambiguity around description field of "fix" #77

New Issue

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

GiteaMirror commented

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

Originally created by @Artoria2e5 on GitHub (Sep 10, 2019).

The descrption specification example of fix is much unlike the descrption given in the summary for fix, and indeed, for every single other type. Compare:

(Summary)
feat: allow provided config object to extend other configs
feat(lang): add polish language
fix: correct minor typos in code 

(Spec)
fix: array parsing issue when multiple spaces were contained in string.

See the problem? Although the spec asks for the description part to describe what the commit does, its very own fix example fails to do that. It thinks the fix type field is good enough for a verb to describe what it does, which it does not in most nontrivial cases.

Devs blindly following that specific example would write awful commit messages like fix: foo bar crashes / not responds / does not work / does undesired thing without describing what the commit does to achieve it. And that defeats the point of conventional commit.

Originally created by @Artoria2e5 on GitHub (Sep 10, 2019). The descrption specification example of fix is much unlike the descrption given in the summary for `fix`, and indeed, for every single other type. Compare: ``` (Summary) feat: allow provided config object to extend other configs feat(lang): add polish language fix: correct minor typos in code (Spec) fix: array parsing issue when multiple spaces were contained in string. ``` See the problem? Although the spec asks for the description part to describe what the commit does, its very own fix example fails to do that. It thinks the `fix` type field is good enough for a verb to describe what it does, which it does not in most nontrivial cases. Devs blindly following that specific example would write awful commit messages like `fix: foo bar crashes / not responds / does not work / does undesired thing` without describing what the commit does to achieve it. And that defeats the point of conventional commit.

GiteaMirror commented

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

@Artoria2e5 commented on GitHub (Sep 10, 2019):

My proposal is that point 5 gets a sub-point that says:

Nontrivial commits with the fix type MUST summarize the change itself rather than the problem it solves in the description. Other verb-form commit types, such as revert, MAY only describe what the operation is applied to, as long as the change is simple enough.

The imperative mood thing seems to be in #85; for some reason it is gone from the current next. Although we run the risk of advertising for a competitor, I strongly suggest http://chris.beams.io/posts/git-commit/#imperative be linked too as it provides some quick ways to check.

@Artoria2e5 commented on GitHub (Sep 10, 2019): My proposal is that point 5 gets a sub-point that says: > * Nontrivial commits with the `fix` type MUST summarize the change itself rather than the problem it solves in the description. Other verb-form commit types, such as `revert`, MAY only describe what the operation is applied to, as long as the change is simple enough. The imperative mood thing seems to be in #85; for some reason it is gone from the current `next`. Although we run the risk of advertising for a competitor, I strongly suggest http://chris.beams.io/posts/git-commit/#imperative be linked too as it provides some quick ways to check.

GiteaMirror commented

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

@wesleytodd commented on GitHub (Sep 30, 2020):

Hey @Artoria2e5, I am not sure that the specification can add much value in this area. I think that a guide/faq could provide recommendations, but as there is now way to validate/parse or otherwise tool around the meaning of the description I don't think there is value in the spec trying to detail expectations there.

@wesleytodd commented on GitHub (Sep 30, 2020): Hey @Artoria2e5, I am not sure that the specification can add much value in this area. I think that a guide/faq could provide recommendations, but as there is now way to validate/parse or otherwise tool around the meaning of the description I don't think there is value in the spec trying to detail expectations there.

GiteaMirror referenced this issue

2026-02-17 11:57:13 -06:00

[PR #85] [MERGED] feat: add imperative present tense requirement #279

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#77