... but it wasn't that (rather, just good arguments and suggestions).
And now I'm wondering if my first thought is a thing? And if so, how it has worked out for users.
I've tried to refrain from endorsing tools because I feel like they risk making it easy to avoid doing what I actually encourage: curating the notable changes for a release with your mushy human brain for other mushy human brains.
I know it's hard, but perhaps it's a good constraint.
The idea that you will have the forethought of knowing when writing a commit that it'll be one of the notable entries in your future changelog seems a bit far-fetched to me. And as I tried to explain, the purpose of a commit is not the same as the purpose of a changelog entry, so there's definitely tension in the re-use of copy there.
I get the instinct to automate everything. I'm just not sure this is something that should be automated. Now, an assistive tool to help maintainers review commits for missing notable changes within a changelog, that's something I could get behind.
We use Phabricator and it’s default workflow, so have a clean linear git history. Phabricator already requires strict formatting for any new diff (title, description, testing, etc). It’s built into the culture of any org using Phab to consider commits as meaningful entries in the history of the project. So it would be very straightforward (technically and culturally) to require a simple title prefix ala Changelog (ADDED, FIXED, SECURITY, etc) for each commit and have yourself a automated and meaningful log.
Not really, your changelog-from-git-log generator doesn't need to incorporate every single commit. The vast majority of commits shouldn't be incorporated in a changelog anyway, since fine-grained commits serve a different purpose. It could incorporate, for example, version-change commits whose messages serve the exact same purpose as changelog entries.
git commit -m "VERSION 1.1.0 <user readable desc of changes since 1.0.0>"https://github.com/aldrin/git-changelog https://asciinema.org/a/Jk8A5UEJGkhlalL4gl3HevC7e
To clarify, not all of your commits need to be user-readable, since the majority of them are meant for developers -- just the sparse ones that capture the version change need to be user-readable.
Then you'd have a full commit history for the nitty gritty details and a subset of your commits would be used to generate a pretty changelog.md for everyone who wants the TLDR.