In my experience, git commit messages are the least useful, because people never look at them, at least in the teams I have been part of. If something is important, it should be right there next to the code. One shouldn't have to `git blame` constantly. The more friction there is, the worse in my opinion. Another issue is that once you start refactoring code `git blame`-ing becomes harder.
The friction is 2 clicks (right-click + show git annotations). And you can leave it open, it's just a small thin strip near the code.
I always check git blame before committing a new code, because I've had this exact experience several times:
- investigate a bug
- find the responsible line with obviously wrong code (often it's even nicely commented and the comments and the code are contradictory)
- fix the obviously wrong code
- commit
- 10 other bugs caused by your fix
- git blame
- turns out the "obviously wrong" line was there on purpose and your fix effectively removed a previous change
- which you would know if you checked the git blame for that line
- comments were lying because somebody did a refactor and didn't noticed 4 lines above there's a whole paragraph of what now became lies
This is Chesterton's Fence rule of programming. Before you change a line of code - be sure to understand why it was there. Git blame is the best tool for that.
BTW there's a similar rule for comments - when you change a line of code in some function - you have to check all the callers of that function (and their callers, etc.) to see if there were any comments near the callers talking about the part that you changed. THAT is the thing that nobody does in practice, and THAT's the reason why comments eventually lie.
