Information that can be automatically extracted from the delta is the least important part of a good commit message. I can figure that part out from looking at the commit later. Instead, what I really want to know is why you made the change. What is the context? What problem were you solving? Why this way and not other ways you might have solved the problem?

A summary of what the change does is still useful, and I'm glad this can now be automated, but it's not the main benefit of a well written commit message.

I disagree. Unless there’s some smarter way to do this, I use the commit messages to find the kinds of historical changes I’m curious about. I want to know what changed. I’m not sure how one would do this unless they’re looking at every commit.

The “why” goes into the PR and more importantly, engineering documentation and inline comments.

Plus, a commit message seems woefully plain and too short to properly communicate these things.

The beauty is that this isn’t prescribed. We can all do what makes sense for our contexts.

This just ensures that the “why” is lost when someone comes looking years later.

From experience, SCM history is far more durable than just about any other work product we produce.

Over five decades later, commit history was still available for the Unix sources and could be reconstructed: https://github.com/dspinellis/unix-history-repo

I’ve used 35-year-old commit messages to help understand a long-standing issue, decades after all other related organization tooling and data had disappeared.