How about the best of both worlds: Keep your changelog-worthy items in the title of your commits and dump those automatically?
Edit: I suppose rather than always forcing yourself into giant commits that are changelog-worthy, you could also do the above with a “Changelog:” preface in the title for such items.
IMO this is the easiest way to implement this sort of thing. When I was working at Calxeda (small team, ~15 full time devs and me) the convention was that all commits on master had to fit the pattern
[<jira ticket>] <short fix message>\n\n<long fix message>.
[<jira ticket>] <short fix message>\n\n<long fix message>
You could do whatever you wanted off on your own working coppies, but when you had something ready to go squash it all down to one patch, write a changelog worthy commit and rebase it onto master. That meant we could just do a git log dump for customers because it was in fact meaningful.
I think the real issue with keeping changelogs is that it requires issue tracker support and there isn’t a convention (besides GH, which isn’t exactly a well defined or open convention) for working with issues and change items from git.
Heh ! I had come up with a similar convention.
I would suggest one more entry to the list – Migrations.
The discussion on HN : https://news.ycombinator.com/item?id=9054627
TL;DR : “There is a standard change log format” and http://xkcd.com/927/