An interdiff is the diff between two versions of the same change. Instead of re-reading a whole pull request after an update, you read only what the author changed between revision one and revision two.
Why does re-review need an interdiff?
First review is well supported everywhere: you get a diff against the base branch and you read it. The second review is where tooling has historically gone quiet. The author pushed fixes, maybe rebased, maybe reworked a section you never commented on, and the platform shows you either the same full diff again or a per-commit view polluted by rebase noise. So reviewers face a bad menu: re-read everything (nobody does), read nothing and approve (everybody eventually does), or reconstruct the delta by hand. An interdiff replaces that menu with the right default: show me revision two minus revision one. We walk through the workflow consequences in our piece on re-reviewing pull requests with interdiffs; this article is just the definition underneath it. The cost of getting this wrong is quiet: the revision that introduces a bug is precisely the one nobody re-read, because it arrived after the hard first pass was already done. Reviewers approve version one carefully and version four on trust, and the delta between those two readings is where regressions live.
Interdiff meaning in git: the range-diff command
Git ships the idea natively as git range-diff, which compares two commit ranges, typically two versions of the same branch, and shows which commits correspond, which were added or dropped, and how each corresponding commit changed. After a force-push you can run something like git range-diff main old-tip new-tip and read precisely what the rework did, rebase and all. The name interdiff itself is older: a standalone utility of that name compared two patch files back when changes traveled as emailed patches, and kernel reviewers still routinely ask contributors to post a range-diff alongside v2 of a patch series.
Where do patchsets come from? The Gerrit heritage
Gerrit, the review system built around the Android project, made revisions first-class: every push to a change under review becomes a numbered patchset, and the UI lets a reviewer diff any patchset against any other. Comment positions carry across revisions, so a thread you opened on patchset 2 is still anchored correctly when you are comparing patchset 2 to patchset 5. That lineage is why review veterans talk about patchsets and interdiffs in the same breath: Gerrit demonstrated that re-review is a solved problem when versions of a change are modeled explicitly rather than as an afterthought.
What GitHub gives you, and where it falls short
GitHub approximates the interdiff. It can show changes since your last review, and viewed-file checkmarks reset when a file changes, which together cover the easy case: new commits appended to the same history. The approximation degrades exactly where you need it most. A rebase or force-push rewrites the commits the comparison was anchored to, comments go outdated, and the since-review view can fall back to showing you everything again. There is no patchset picker, no durable revision history to diff against. Until the platform models revisions properly, reviewers cover the gap with git range-diff locally or with review tools built around the returning reviewer (disclosure: our own Pyor is one attempt at that). However you get one, the test of a review tool is the second look, not the first.
Frequently asked questions
What is the difference between an interdiff and git range-diff?
An interdiff is the concept: the difference between two versions of a change. git range-diff is the built-in git command that produces one, comparing two commit ranges and showing how each commit changed between them. Older tooling also had a literal interdiff utility for comparing patch files.
Does GitHub show an interdiff?
Approximately. GitHub can show changes since your last review, and its viewed-files checkmarks reset when a file changes. But a force-push rewrites history and can break that view, and there is no first-class revision picker like Gerrit patchsets, so the approximation fails exactly when rebases happen.
Why not just re-read the whole pull request?
Because full re-reads do not scale and reviewers do not actually do them. Faced with a 40-file PR updated for the third time, most reviewers skim and approve. An interdiff shrinks the third look to the handful of lines that changed, which keeps re-review honest.
