I don’t think this is a good rule. 1) I can’t see “git blame” in my code review. Don’t make me check out the branch to review your changes. 2) If we refactor

I don’t think this is a good rule. 1) I can’t see “git blame” in my code review. Don’t make me check out the branch to review your changes. 2) If we refactor the code (say, extract a new class wrapping the functionality) then the explanation in git becomes much harder to find. If it’s a comment you can just copy it over. You should explain the change set in your git comments too, but at a different level of abstraction - why is this whole set of changes being made? What problem is being solved? What’s left to do? Etc. this stuff can’t usually be associated with a particular line of code. So inasmuch as you are arguing for good commit messages I strongly agree. But I disagree that this should be at the expense of good comments in your code.