That angular commit message is a crime.

My squashed commit messages typically enumerate everything I changed and why.

IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.

I think we agree on this.

One case that has come up for me several times: working on a feature, committing as I go. And then I realize some of what I did won’t work or isn’t what product actually wants. Leaving those commits in the history that show the function doing the wrong thing would be misleading. Especially if that was never actually in production or left my local machine.

I guess I have an unspoken belief that every commit on main should work, but you could achieve that with tags instead.

I was recently spelunking to try to find why something in old code was the way it was. I found the commit where they changed the line, but it was orphaned from the larger context. The message didn’t say more than like “change field from footype to bartype”, but not why. So I had to try to piece together what other changes were part of this change. If it had been a single commit that showed them like adding the new field, new model, and whatnot, it would have been clearer to me that those things all go together.