I think the issue with automation is it requires a cultural change for most companies / projects. People are very used to small atomic commits and so it’s hard to reduce the noise once parsed into a changelog. To make it work, you need each commit to be as meaningful as a line in the changelog.
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.
> you need each commit to be as meaningful as a line in the changelog.
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>"
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.