Some of us like "interdiff" code review

Original Article ↗ Hacker News Discussion ↗

Many developers argue that GitHub’s pull request model produces “diff soup” that is hard to review incrementally, especially after rebases or multiple feedback rounds, and prefer systems like Gerrit, Phabricator, or email-based workflows that support interdiffs and stacked, versioned patch series. They contend that commit-centric, rebase-friendly workflows—with every commit building and passing tests—improve review quality, history clarity, and tools like `git range-diff`, while GitHub’s UX nudges teams toward squash merges and noisy fixup commits. Others point to emerging tools layered on top of GitHub (e.g. stacked-PR CLIs, alternative VCS like Sapling or Jujutsu, and third-party review platforms) as attempts to recover these benefits without abandoning the GitHub ecosystem.

Interdiff / incremental review model

  • Many agree with the article’s core claim: reviewing “versions of a patch stack with interdiffs” is far clearer than GitHub’s “diff soup.”
  • Interdiffs let reviewers see only what changed since the last round, without fixup commits or rebases obscuring context.
  • They work well whether changes are a single logical unit or a multi-commit series.

Gerrit / Phabricator / Review Board vs GitHub / GitLab

  • Gerrit and Phabricator are widely praised for:
    • Treating the commit/patch as the unit of review.
    • Native stacked changes, interdiffs, and “attention set”–style workflows.
  • GitHub is seen as author-friendly but reviewer-hostile: vertical-space-heavy UI, weak handling of rebases/force pushes, comments going “outdated,” and poor big-picture discussion.
  • Some say GitLab supports versions and interdiff-like views, but its naive handling of rebases and very slow UI are major complaints.
  • Review Board is cited as an early system with good interdiff support.

Stacked commits, PRs, and rebasing

  • Many want small, logically independent commits that all build and pass CI, organized as stacks.
  • GitHub’s branch/PR model makes stacked diffs clumsy; dependent PR chains are fragile, especially for external contributors.
  • Some teams emulate stacked diffs with fixup commits + interactive rebase, or with “stacks of PRs,” but this is error‑prone and UX-hostile.

Squash vs preserving history

  • One camp favors squash-merge for clean mainline history and CI‑green bisect points.
  • Another camp insists on keeping fine-grained, ordered commits to aid blame, bisect, and understanding design evolution.
  • Several note the ambiguity between “squash all into one” vs “squash WIP/fixup into meaningful atomic commits.”

Email workflows and git-range-diff

  • The email + git format-patch + git range-diff model is held up as the conceptual gold standard for interdiff review.
  • Pros: perfect incremental review trail, strong threading, good for long-lived series.
  • Cons: email UX is considered painful and discouraging for many.

Tools and alternatives

  • Multiple tools are mentioned that try to bring stacked diffs/interdiffs to GitHub (Graphite, Aviator’s CLI, ghstack, spr variants, Sapling, Jujutsu, stgit).
  • Experiences vary: some report big productivity wins, others report bugginess, complexity, and churn.
  • There is interest in new VCS or higher-level models (Sapling, Jujutsu, Pijul, Mercurial) that better support stacks and history editing.