Commit messages could just as easily be a policy requirement instead of a tool requirement. Maybe all the repos you interact with require a message for every commit, and that's fine.
But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion.
And, honestly, 90% of all commits I've seen use crap messages like "stuff", "fixes", or "change 357" that are so devoid of useful content that I'd argue that those commits would be better off with no message at all. Just date and author. At least then you won't be distracted by contentless messages that can't even be self-consistent most of the time. This isn't a swing at those people, I'm just being realistic.
I would rather go the other way. Commit messages should be modifiable by themselves. The idea that commit messages will be gotten right on the first try predates CVS and it’s just wrong.
Who hasn’t put the wrong bug number on a commit? You’re stuck with that. Who hasn’t confidently remarked that they have solved a problem and then discovered they haven’t? Commentary about a block of code needs to be a living document every bit as much as the code it refers to.
Two years from now when you’re trying to figure out what the hell you were doing in a block of code, the message is going to be wrong and everything you’ve thought about it since is gone, except what you can remember.
For a second I thought you found something I didn’t know about git but then I realized I dismissed notes out of hand. They’re not managed automatically so it’s pointless for me to try to sell a large team on using them. We already work with multiple repos and doubling the workflow won’t be appreciated.
And if I recall isn’t it a pain to add additional notes?
"Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about.
I'd argue that for any piece of software where a failure requires a root cause investigation the VCS history is a critical artifact and a great deal of care should be taken to make it easy to understand for what reasons changes happened and how they interact.
There are a lot of very sophisticated things you can do with and to a body of code to fix extremely complicated problems, but the information needed to do so is at times quite delicate.
The overlap of people who believe in Bad Luck and don’t care about transparency is pretty high. Things just are, there’s no one to blame and certainly no lessons to be learned.
They don’t get how a breaking the commit history with a mangled move operation or shitty merge will fuck is over eighteen months from now. Hell half of these people think they’ll be retired or working someplace else 18 months from now anyway.
> "Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about.
Realistically, though, you won't be able to figure out to which task management system this issue number refers, out of the five that your team used in the last 3 years. We have been through two different JIRAs and two different Github trackers in the last 3 years. Sometimes multiple simultaenously.
Also, whenever you write /#\d+/ in a Git commit, GitHub will stubbornly assume that the number refers to Github issues and PRs, even if it doesn't. And some of our repos use both Github issues (for external input) and JIRA issues (for internal planning).
If you switch issue trackers every ten months without a migration strategy for old issues that's a pretty serious organizational problem. I hope that's not a mature company.
I think in feature branching workflow it would be more useful for the branch to have a message not the commit. Commit is way too small of a unit to be meaningful more often than not.
But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion.
And, honestly, 90% of all commits I've seen use crap messages like "stuff", "fixes", or "change 357" that are so devoid of useful content that I'd argue that those commits would be better off with no message at all. Just date and author. At least then you won't be distracted by contentless messages that can't even be self-consistent most of the time. This isn't a swing at those people, I'm just being realistic.