A New Git Diff Algo

GitHub’s diff experience is getting a rethink: a newer diff strategy called “commit cruncher” is designed to cut the amount of code reviewers must visually parse by recognizing more kinds of changes than the classic Myers diff. Myers—named for Eugene Myers’ canonical algorithm—treats line differences largely as add/delete operations between two repo snapshots, which can make refactors look like large, noisy edits even when most of the work is moving code around or making trivial updates.

The research behind commit cruncher argues that expanding the diff “vocabulary” (adding operations like move, update, find/replace, and copy/paste) can produce a more compact, reviewer-friendly representation of a pull request. In practical examples, whitespace-only changes can be treated as low-signal updates so reviewers focus on meaningful edits. Refactors that extract code into a new function can be shown as a smaller set of “what changed” events rather than thousands of lines appearing as rewritten. The approach also aims to preserve context for multi-step edits—such as when a rename happens and later commits modify the renamed file—by tracing how each changed line evolves across the commit sequence.

The core workflow shift is important: Myers diff compares only the repo state before and after a commit, while commit cruncher takes a more computationally intensive route by tracking each changed line through the commits where it appears, building a “commit group” view. The payoff claimed in the research is twofold: fewer highlighted lines to review and better reviewer context. One benefit described is that hovering over a line can surface the commit messages that explain why that line ended up in its final form. Another is that when a line is moved and then modified, the diff can show the original location and evolution rather than forcing reviewers to reconstruct the story from two endpoints.

Empirical results are presented using 12,638 pull requests processed in the second half of May 2024, spanning popular open-source projects (including React, VS Code, Chromium, and TensorFlow) and SaaS repositories. Using GitHub’s API compare endpoint as a baseline, the study reports “28% fewer lines to review” on average when commit cruncher’s diff highlighting is used instead of Myers-style highlighting. A separate experiment with 48 developers assigned to review pairs of pull requests on GitHub vs the commit cruncher platform found no meaningful difference in question accuracy (with differences under 5%), while review duration decreased in the direction expected.

Still, the evidence comes with caveats. The reported “lines to review” metric is a proxy for effort, not a direct measure of comprehension difficulty or bug-finding outcomes. Review time can drop even if the underlying cognitive load shifts elsewhere, and real-world code review includes confounders like reviewer familiarity, language expertise, and the nature of the changes. Even so, the broader takeaway is clear: diff algorithms shape how humans interpret change, and moving beyond Myers’ add/delete framing could reduce the visual noise that slows reviews—especially for refactors, moves, and incremental edits.