4 ms·

Git Commit message conventions for Angular.js

25 points by jackweirdy 12y ago

hmpc 12y ago
Message body just as in <subject> use imperative, present tense: “change” not “changed” nor “changes” Is it me or is this directly contradicted by the examples at the end? Which, by the way, seem much more natural than they would be if they obeyed this convention.
- laughinghan 12y ago
  Yeah, they miss this in several examples ("updated", "added", "fixed"). I know where you're coming from, it feels more natural because when you ask yourself "what did this change do?" to write the commit message, the answer is in past tense. They fail to mention the reasoning behind the convention, which dates back at least to tpope's 2008 blog post[1] and is also in Documentation/SubmittingPatches in Git's own repo[2], which is that not only does the imperative tense tend to be slightly more concise, but more importantly, it's consistent with automatic commit messages generated by commands like git merge and git revert. [1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... [2]: https://github.com/git/git/blob/master/Documentation/SubmittingPatches https://github.com/git/git/blob/master/Documentation/Submitt...
Kiro 12y ago
Looks really contrived and overengineered if you ask me.
- greggman 12y ago
  Agreed. I don't even understand the point of a CHANGELOG file. It seems like that whole idea is left over from before source control. Having a CHANGELOG file was one of the absolute worst parts of contributing to WebKit since everyone is required to edit it with every commit its the biggest source of conflicts. Of course automating its generation I guess is trying to fix that but I just don't get why you can't just do `git log` or equivalent when you need info. Why does a CHANGELOG file need to exist at all. I also don't get why anyone cares. I never looked at CHANGELOG ever. I'd use the various source control tools to find changes, who modified, etc.
  - mercurial 12y ago
    Changelogs are very nice. Debian packages always include one, and it's particularly useful when you want to find out what changed since the last install, especially if security is a concern.
  - daigoba66 12y ago
    As a user of open source software, I love changelogs. It gives me a concise index of high level changes between official releases. But I certainly don't want one line per commit.
- atjoslin 12y ago
  It's actually very simple. This document is just way too hard to read. Prefix with the type of the change. Put the scope of the change in the parentheses. Put the description afterwards. Did you fix the caramel filling in the ChocolateFactory? `fix(ChocolateFactory): make caramel filling work` Here's a more succint description: https://github.com/ajoslin/conventional-changelog/blob/master/CONVENTIONS.md https://github.com/ajoslin/conventional-changelog/blob/maste...
davexunit 12y ago
I recommend adopting the The GNU ChangeLog format. My commit messages have been much better since adopting the standard. https://www.gnu.org/prep/standards/html_node/Change-Logs.html https://www.gnu.org/prep/standards/html_node/Change-Logs.htm... Example commit: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=0a90af153199b03deced53da7ef7f50f0e561f80 http://git.savannah.gnu.org/cgit/guix.git/commit/?id=0a90af1...
tzs 12y ago
It would irk me to work with those conventions, for a trivial and insignificant reason: I see no justification for using "feat" as the type for a feature change message instead of "feature". The length of the string "feature" does not appear to be a justification, because they type for a refactor change message is "refactor", which is longer than "feature".

25 points by jackweirdy 12y ago

hmpc 12y ago

Message body just as in <subject> use imperative, present tense: “change” not “changed” nor “changes” Is it me or is this directly contradicted by the examples at the end? Which, by the way, seem much more natural than they would be if they obeyed this convention.

laughinghan 12y ago
Yeah, they miss this in several examples ("updated", "added", "fixed"). I know where you're coming from, it feels more natural because when you ask yourself "what did this change do?" to write the commit message, the answer is in past tense. They fail to mention the reasoning behind the convention, which dates back at least to tpope's 2008 blog post[1] and is also in Documentation/SubmittingPatches in Git's own repo[2], which is that not only does the imperative tense tend to be slightly more concise, but more importantly, it's consistent with automatic commit messages generated by commands like git merge and git revert. [1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... [2]: https://github.com/git/git/blob/master/Documentation/SubmittingPatches https://github.com/git/git/blob/master/Documentation/Submitt...

Kiro 12y ago

Looks really contrived and overengineered if you ask me.

greggman 12y ago
Agreed. I don't even understand the point of a CHANGELOG file. It seems like that whole idea is left over from before source control. Having a CHANGELOG file was one of the absolute worst parts of contributing to WebKit since everyone is required to edit it with every commit its the biggest source of conflicts. Of course automating its generation I guess is trying to fix that but I just don't get why you can't just do `git log` or equivalent when you need info. Why does a CHANGELOG file need to exist at all. I also don't get why anyone cares. I never looked at CHANGELOG ever. I'd use the various source control tools to find changes, who modified, etc.
- mercurial 12y ago
  Changelogs are very nice. Debian packages always include one, and it's particularly useful when you want to find out what changed since the last install, especially if security is a concern.
- daigoba66 12y ago
  As a user of open source software, I love changelogs. It gives me a concise index of high level changes between official releases. But I certainly don't want one line per commit.
atjoslin 12y ago
It's actually very simple. This document is just way too hard to read. Prefix with the type of the change. Put the scope of the change in the parentheses. Put the description afterwards. Did you fix the caramel filling in the ChocolateFactory? `fix(ChocolateFactory): make caramel filling work` Here's a more succint description: https://github.com/ajoslin/conventional-changelog/blob/master/CONVENTIONS.md https://github.com/ajoslin/conventional-changelog/blob/maste...

davexunit 12y ago

I recommend adopting the The GNU ChangeLog format. My commit messages have been much better since adopting the standard. https://www.gnu.org/prep/standards/html_node/Change-Logs.html https://www.gnu.org/prep/standards/html_node/Change-Logs.htm... Example commit: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=0a90af153199b03deced53da7ef7f50f0e561f80 http://git.savannah.gnu.org/cgit/guix.git/commit/?id=0a90af1...

tzs 12y ago

It would irk me to work with those conventions, for a trivial and insignificant reason: I see no justification for using "feat" as the type for a feature change message instead of "feature". The length of the string "feature" does not appear to be a justification, because they type for a refactor change message is "refactor", which is longer than "feature".