A specification for adding human/machine readable meaning to commit messages

This seems like a great idea, but in practice I found it lacking.

The big use case I see for this is to drive automatic generation of changelogs and automatically computing the next semantic version of your project. Which is a very cool idea.

The problem is that unless you carefully write every commit message in a way that makes sense for your product's changelog, the changelog ends up being unreadable garbage.

On top of that, if you're working in a monorepo, any given commit may impact multiple projects. How do you write those commit messages to make sense for three different projects? You'll always wind up with irrelevant crap in your changelog.

This problem gets magnified even further if your team is squashing commits with each PR. This means you can't even keep a discipline of isolating all the changes on a single commit to a single project. Another issue is that you can't use linters on your PR commit messages on github, so your squashed commits aren't verified to be correct.

I still love the core idea and I wish it worked better for my use cases.

Tbh I really don't like this.

Git already has an established format for machine-readable metadata, trailers. There's even a built-in command for working with them, git interpret-trailers. This pulls data-for-computers into an area that should be data-for-humans.