> Same as having a standard coding style, you should have a standard commit message style that you do care about for every commit in the project. A mish-mash of variable quality and variable formatted commits more than subjectively looks bad - it reduces the signal-to-noise of the commit messages.

I already personally use a standard commit message style.[1] And that standard is about how to structure the prose, not about using any kind of structured markup (outside the trailers section).

> As for the `feat(scope):` in the subject line, it's a very succinct way to communicate the type of the change. Don't make me the read the whole commit to figure out if this was a feature or bug fix, or only affected the build.

Verbs already serve that purpose most of the time. Then you get redundant lines like `feat: add OAuth 2.0 login`.

> Sure. But I want the changelog to list features first, then bug fixes, etc. How do I do that automatically with only the git log w/o some sort of standardized tagging of the commits?

If you have such a high volume of commits (that users would care about) that you have have distribute tagging of all commits to all contributors,[2] you can use the trailers section.[3]

[1] I don’t expect anyone else to at work. In one free-time project people use the same style, with one exception (against my personal taste).

[2] And if you need such a detailed changelog, let alone a fully automatically written one

[3] https://news.ycombinator.com/item?id=40820213