If you have git blame, you can see a detailed log messages pertaining to the commits which touch some lines of code. You don't need it to be littered by comments.

You seem to think that git invented blame. This appeared in previous version control systems, e.g. "cvs annotate" whose synonym is "cvs blame".

Put the comments in git commit messages! Ha, that’s a good laugh. There are so many shortcomings to this, I don’t even know where to begin.

Nick checks out.

The obsession people seem to have with squashing commits in git (particularly on merge) means they're right, you can't really rely on commit messages still containing relevant information.

* * *

I don't consider comments litter. Commit messages rarely have the amount of context needed for a specific block of code.

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.

yeah, if you can do commits per function that would be fine. Most projects don't allow that, everyone squashes commits these days.

* * *