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.

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-messa...

[2]: https://github.com/git/git/blob/master/Documentation/Submitt...

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.htm...

Example commit: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=0a90af1...

Looks really contrived and overengineered if you ask me.

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/maste...

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.

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.

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.

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".