I write GNU-ChangeLog-style commit messages which mention every function and other named entity touched, added or deleted, with details about why. Between that and the diff, you can figure out exactly what was done and why, matching the comment with specific code blocks.
I've never been disappointed when digging back in history to figure out why the heck something was done.
It would be a strawman of my position to say that I'm favoring zero comments. For instance, a /* fallthrough */ comment in a C switch statement cannot be in a commit comment, not the least reason for which being that compilers look that that nowadays.
Comments should be like road signs. I need a warning about a dangerous curve ahead, not a discussion of why it was built that way.
If that's an argument so is this: most coders don't like commenting, nobody bothers, comments are haphazard and unmaintained. Just skip them.
You don't seem to have understood my remarks; It's not "commit per function", but cover each function that was touched (or other entity: class, global variable, type, object member) in your commit comment.
When someone does "git log" they should be able to search for the name of a function of interest and see all commits which touch it, explaining what was done to it and why.
Banish squash commits; it's a poor CM practice. If you're not able to get your developers to commit to a good practice, then that's your main problem. You have to fix that before engaging "comment versus commit".
I've never been disappointed when digging back in history to figure out why the heck something was done.
It would be a strawman of my position to say that I'm favoring zero comments. For instance, a /* fallthrough */ comment in a C switch statement cannot be in a commit comment, not the least reason for which being that compilers look that that nowadays.
Comments should be like road signs. I need a warning about a dangerous curve ahead, not a discussion of why it was built that way.