Git blame only shows you the last person that touched the line, not the person who introduced a breaking change to that line (but it wasn't caught for weeks/months).
Comments are just as cheap as commit messages. Why not both?
Git blame can also show you the last revision which touched a file since some revision. Git log on a file can show you all the revisions in which it was touched. Using these together lets you slice the history in many useful ways, and there are countless gui-based tools (git gui, for example) which also allow you to explore revisions.
Whereas the commit is immutably and ideally exactly about what it's about. There is no better time to capture the information in a way that perfectly connects it to what it's describing.
While commit messages are always there, they get lost. You fix a bug in your code, with a commit message. Later, you realize that this function is super reusable, so you move the function to another class in another file. Now, for all intents and purposes, the original commit message will never be seen again.
It's harder to find originals under such circumstances, sure. But I don't see this as a reason for never writing good messages, because a journal of intent is strictly better than a journal of physical amendments.
That something needs to be entirely perfect before being judged better than the status quo is the Nirvana fallacy.
I don't think anyone is arguing for "never writing good messages"; the point is that you can have both good commit messages and good comments, both of which are useful for different reasons, and you don't need to give up one to have the other.
It shows you the commit that introduced the current version of the line. That's what you want if you want to understand the current version of the line.
I feel like I'm missing something here. I hate this feeling of impending dumb.
Got it. It's still possible to keep stepping back through the history of that line to understand its exact history.
I also typically find most files have only a handful of commits of interest in their history, so scoping a git log to the file often gets me within spitting distance of the right commit, if someone took the time to write a good one.
Edit: which goes back to my original point, that the commit is the best time and place to snapshot the meaning of that time and that place.
I agree, but you must also concede that not all developers are as proficient at git as you and might not be aware of such debugging/detective techniques. These same developers tend to favor print statements for debugging instead of an actual debugger. Also, not every developer has the privilege of using a DCVS like git.
For them, a comment in the code could save a lot of time and hassle.
