Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ambiguity around description field of "fix" #190

Open
Artoria2e5 opened this issue Sep 10, 2019 · 2 comments · May be fixed by #196
Open

ambiguity around description field of "fix" #190

Artoria2e5 opened this issue Sep 10, 2019 · 2 comments · May be fixed by #196

Comments

@Artoria2e5
Copy link
Contributor

Artoria2e5 commented Sep 10, 2019 •
edited
Loading

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.
@Artoria2e5
Copy link
Contributor Author

Artoria2e5 commented Sep 10, 2019 •
edited
Loading

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 Artoria2e5 linked a pull request Sep 11, 2019 that will close this issue
Open
@wesleytodd
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: recommend imperative mood, with emphais for fix Artoria2e5/conventionalcommits.org
2 participants
@wesleytodd @Artoria2e5