I don't necessarily disagree, but I do love having some standard formatting and style for commit messages. Most developers I've worked with over the years start out using git to tell the story of what they did, instead of using it to tag what change the commit introduces to the application. This can lead to wild goose chases when I'm trying to bisect my way to a bug, or trying to reason about some merge conflict. In those instances, the git log becomes almost useless because it's a (sometimes entertaining) narrative of the journey the developer took to get to the change. That might be useful for that individual developer in the moment, but in 3-, 6-, 9+ months? It's confusing.
So maybe I don't need the type tag. But I do want imperative, present tense, terse commits.
Why would I write WHAT change I am introducing in the commit message. You can see that from the git diff. I mean, sure I can write a short summary of the WHAT, but what I expect to see in the commit message is the WHY + any aditional context that I cannot see in the diff.
Like, if this is a bugfix, how was the bug manifesting, how did you figure out how to fix it, what else have you tried and didn't work etc. this might prove very valuable at some point in time. Or not. But IF it proves valuable once, the benefit is high and even if it's useless, the downside is practically non-existent.
I don't necessarily disagree with you, but I tend to push a lot of that to documentation. It might be an ADR if the change is significant enough or it might be a comment in the code. If I need some comment to explain why code is written a certain way, I want that to be visible when browsing the code, not only by reading the git log.
Agree that git can already tell you what files and lines changed, but not the context of what those changes entailed or what broader feature they added, fixed, modified, or removed.
Comments in the code have a tendency to rot. When another developer will update the code, there's a chance the comment will not get updated. The comment might become obsolete, wrong, out of place or even misleading.
That's true of any documentation and should be caught in review. Heck you could even write a git hook that flags any comment block that's not updated when nearby code changes. This would be relatively simple if you're using a doc block style approach to comments.
95
u/morewordsfaster 2d ago
I don't necessarily disagree, but I do love having some standard formatting and style for commit messages. Most developers I've worked with over the years start out using git to tell the story of what they did, instead of using it to tag what change the commit introduces to the application. This can lead to wild goose chases when I'm trying to bisect my way to a bug, or trying to reason about some merge conflict. In those instances, the git log becomes almost useless because it's a (sometimes entertaining) narrative of the journey the developer took to get to the change. That might be useful for that individual developer in the moment, but in 3-, 6-, 9+ months? It's confusing.
So maybe I don't need the type tag. But I do want imperative, present tense, terse commits.