I’m not a big fan of the git merge-based workflow, but I must admit that the merge commits can be pretty neat. After resolving a bunch of merge conflicts it is often beneficial to see what changed in the process and the changeset contained in the merge commit does provide just that. But how do you do that with rebase?

In the example above we would essentially like to see what changed between mycommit and mycommit_fixed and using

git diff mycommit mycommit_fixed

might be the first idea that comes to mind. I know I tried it and, as anyone else who did, I found out that it does not help much. I mean, the information I was looking for was there, but so were all the other changes introduced by the divergent history. This is less helpful than looking at the changes introduced by the commit and trying to figure out if everything is still in order.

This happens because we’re not comparing the changesets introduced by the two commits: we’re comparing the whole file trees. What we want instead is a diff of the changesets, a diff of diffs.

I run into this problem from time to time and mostly end up remembering that the simple diff does not work and just giving up. However, recently I came across a git command that was new to me: git range-diff. From the relevant man:

This command shows the differences between two versions of a patch series, or more generally, two commit ranges (ignoring merge commits).

Sounds like just what we need and then some. The basic syntax is:

git range-diff <commit-range-1> <commit-range-2>

Translating it to our problem, as seen in the diagram:

git range-diff mycommit^..mycommit mycommit_fixed^..mycommit_fixed

Try it, it’s pretty cool.