Diffing diffs

git range-diff (introduced in Git 2.19) compares two ranges of commits, pairing them by similarity and showing the inter-version changes. It is indispensable when reviewing patch series rerolls or comparing rebased branches.

Basic invocation

git range-diff main..topic-v1 main..topic-v2
git range-diff topic-v1...topic-v2
git range-diff origin/main...HEAD

The triple-dot form takes a single argument: the symmetric difference around a base. Useful when both topic branches share that base.

Reading the output

Each line begins with a pair of indices and a status:

• = commit unchanged.
• ! commit modified — followed by the inter-diff.
• < commit only in the first range.
• > commit only in the second range.

Practical use: pre-merge review

Before force-pushing a rebased PR, sanity-check what changed:

git range-diff @{u}...HEAD

This compares the upstream branch tip to your local HEAD, showing exactly which commits moved, were rewritten, or were added.

In cover letters

For mailing-list workflows, paste range-diff output into the v2 cover letter:

git range-diff main..topic-v1 main..topic-v2 >> out/v2/0000-cover-letter.patch

Reviewers see the per-commit changes since v1 without re-reading the full series.

Tuning

git range-diff --creation-factor=70 main..a main..b
git range-diff --no-color-moved main..a main..b
git range-diff --left-only main..a main..b

--creation-factor controls how aggressively commits are paired by similarity (higher means more willing to pair near-rewrites; default 60).

Common mistakes

Comparing across different bases without realizing it — range-diff implicitly aligns by content but a different base can produce noisy "modified" markers. Misreading = as "identical" — it means content-equivalent; the SHAs may differ. Using triple-dot when the two branches do not share a base; results will confuse rather than illuminate.

Related

See "Maintaining a patch series with git format-patch", "Interactive rebase mastery", and "Advanced git log: formatting, filtering, and graph".