Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
And for old enough code, the author may not be available, or more likely doesn't remember.
It feels like we're trying really hard to stretch the utility of commit messages here...
I don't feel that is an accurate statement for any complex system.
1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan.
2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.
Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.
> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.
If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.
Links to ticket IDs are good, and good leaders don’t let old ticket links break on bugtracker migration.
A sentence or so to let future devs know what this change meant to do or at least what initiative it was intended to support, is also good. If future devs (even future YOU) don’t know what you were trying to do, they might revert a change which, without context, looks like a mistake.
Doing both ticket link + text is ideal because someone might screw up the ticket system, and a sentence on its own can be ambiguous.
Doing neither, on purpose, is just willful stupidity. Don’t even bother with Git if you want your commits, the ones that end up in “dev” I mean, to all just say “wip,” “asdf,” and “hope it works now.”