alt Hacker NewsI love how the author thinks developers write commit messages.
All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now".
It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful.
AI generated commit messages helps this a lot, if developers would actually use it (I hope they will).
Replies
In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.
If developers don't write commit messages, that's a culture problem. At my company we demand that of each other.
Only two of the five depend on commit messages. Churn, authorship, and velocity work regardless. Even teams with terrible hygiene write "fix" when something breaks.
Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.
> It's a small minority
Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff").
I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.
I personally use git commit -m "." for: "Just snapshots this state real quick" on a feature branch.
main branch is advanced on PR level, with squashed commits.
So the "." should never make it to main, and have PR description as commit message.
tbh I'm not convinced that a git log history should be treated as a group journal because it's not.
relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it's just necessary to hit the save button real quick or move a workspace from one device to another.
my point is: git is a way of storing and loading files at its core.
Bad commit messages always fail PR review for me. It requires will and discipline, but it's not that hard.
Only two of the five insights are based on commit messages and the author acknowledges that they won't work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.
Commit messages are often squashed after merging a feature branch
> AI generated commit messages
git log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)
I love how the commentator thinks a developer makes decisions based on commit messages.
Random, subjective, or written in a state of mental exhaustion commit messages.
I also love the switcheroo the author made: git not logs. But hey :)
It's because the vast majority of commit messages are never read by anyone, and there's other ways to fund out what happened in the handful of cases where you would need to.
This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.