"A good commit consists of multiple elements, but at a minimum, it should have a well-crafted commit message. " I'm not sure I accept this premise. Just a few words is all that is needed. Anymore and it becomes this OCD novel you are writing that doesn't actually help the code base later. Git log -p is where you really look to see what the commit did, not a well crafted message.
The diff will tell you what's changed, but it doesn't tell you the "why" of the change. A project should store that information somewhere; whether it's in pull request descriptions, issues/tickets, or the commit message, which is a perfectly reasonable choice.
I omit very obvious stuff from the git commit if it is visible in a diff, for example if I change "a" to "b", my commit message is not going to be "Changed a to b", but something more general, not too specific, that is what the diff or source code is for.
A well-crafted commit can have a few words or five paragraphs. A few words will never be enough for a non-obvious change.
Some people might then say “use code comments”. But those inline comments won’t work when you have five years of source code change and those three lines deserve a cumulative seven comments.
commit messages can be useful sometimes to explain the context of a change, but I agree if the code doesn't speak for itself then adding a comment above it is probably a better, more permanent solution.
A code comment can tell you why the code is the way it is, but it shouldn’t tell you why it changed. That’s what commit messages and/or PR descriptions are for.
