[hmeh]

Author here. Yes, the diff should tell you more, but you shouldn't need to look at the diff until you have an idea what the contents of that diff are about. It's like the links on the hacker news home page -- clicking them will always tell you more, but the index should be geared for the use case, which is scanning, typically.

[sverhagen]

I'm not sure that suits everyone's most common use case. (I'm not arguing that it may well suit yours.) I guess on paper it makes sense that commit messages are the top-level entry point to changes. But since we're packaging up a lot of our work in merge requests, the commit messages already get snowed under. Folks arrive in a merge request, and often can't care less about the commit messages that make up the merge request, they may read the message on the merge request, familiarize themselves (ideally) with the story in (ugh) Jira, and then jump to the diff for the review they came there to do. It's the later version of you that is browsing through the code base and wants to understand how a certain current piece of code came about, who then clicks on the gutter in, let's say, IntelliJ, and clicks through to the commit, where both the diff and the commit message are shown.

[hmeh]

Indeed, and since we don’t do pull requests (we pair, mob, and/or do live code reviews), the after-the-fact git blame or the git log to see what has changed recently is what tends to matter.

I agree that when I did PRs I didn’t tend to care about the commit messages when I was reviewing them, but even when I did do PRs I cared about them later any time I was trying to understand how, why, or who forensically.