devtools
guide
17 Oct 2026
Four diff algorithms over 800 commits, and the 2.5 percent where it mattered
Ran every git diff algorithm over the same 800 commits and hashed the output. They disagreed on twenty of them, and one of the four never produced a different byte at all.
By Purvansh Parmar
Checked 2026-10-21
Read 7 min
Entries 5
Someone on your team swears by histogram. Someone else sets patience in their global config and tells people it produces better diffs for code review. Both of them are arguing about something that changes 2.5 percent of their commits. I ran all four algorithms over 800 real commits and compared by hash, and the surprise was not which one won. It was that one of the four, the one whose name promises the most work, never produced a different byte from the default on any commit in the sample.
How this was checkedRan all four git diff algorithms over the same 800 non merge commits of expressjs/express and compared the output by hash rather than by eye. Twenty commits produced any disagreement at all. The minimal algorithm produced byte identical output to myers on every single commit, 800 out of 800. On the twenty that did differ, patience and histogram produced seven fewer hunks than myers but slightly more changed lines.
What I compared on
- how often the algorithm changes the output at all, measured by hash
- hunks produced on the commits where they do differ, since a hunk is a place the reviewer must look
- changed lines, since those are what the reviewer must actually read
The default, an implementation of the 1986 Myers algorithm that every git install uses unless told otherwise.
Wins
It is what every reviewer, every tool and every piece of CI already sees, so its output is the shared reference. It is also teh fastest of the four on large files, since it is not doing the extra passes the others are.
Loses
It is the one that most often splits a logical change into more hunks than it needs: seven more than patience over the same twenty commits, which is seven extra places to look.
299 hunks2,575 addedthe default
An extension of patience that ranks occurrences of each line, and the one most often recommended as a global default.
Wins
It gets patience's hunk reduction while staying closer to myers on line counts than patience does, which makes it the best of the four on the only axis where they actually differ.
Loses
The gain is 18 commits in 800. Setting it globally is defensible, arguing for it is not, and it is slower than myers on files with many repeated lines.
18 of 800 commits292 hunks2,577 added
Matches only lines that appear exactly once on each side, then recurses, which is meant to avoid matching stray braces.
Wins
It is the easiest of the four to reason about: unique lines anchor the diff, so a moved block tends to come out as a moved block rather than as a shuffle of braces.
Loses
It reports the most changed lines of any algorithm here, 7 more added than myers over twenty commits, so the reviewer reads slightly more to look in slightly fewer places.
16 of 800 commits292 hunks2,582 added
Myers with extra work permitted to find the smallest possible diff, documented as spending more time to do so.
Wins
There is nothing to say for it on this corpus, which is itself the useful result: if you have this set in a config somewhere expecting it to do something, it is not doing anything.
Loses
It is documented as taking extra time, and it bought zero changed bytes across 800 commits. That is a cost with no observed benefit on ordinary source files.
0 of 800 commits differed299 hunks, same as myersidentical hashes
Not an algorithm but a post pass that shifts hunk boundaries to line up with indentation, on by default since git 2.14.
Wins
It is the one setting here that is both already on and doing visible work, and it improves exactly the case people blame the algorithm for: a hunk that starts in the middle of a block.
Loses
It only moves boundaries, so it cannot fix a genuinely bad alignment, and because it is on by default it is invisible in every comparison of the four algorithms that people actually argue about.
11 of 800 commits1.4 percenton by default since 2.14
Side by side
| Differs from myers | Hunks on the 20 | Added | Removed |
|---|
| myers (default) | baseline | 299 | 2,575 | 1,561 |
| minimal | 0 of 800 | 299 | 2,575 | 1,561 |
| patience | 16 of 800 | 292 | 2,582 | 1,568 |
| histogram | 18 of 800 | 292 | 2,577 | 1,563 |
| indent heuristic off | 11 of 800 | n/a | n/a | n/a |
Verdict
Set histogram globally and stop thinking about it. It produced the fewest hunks of any algorithm while staying closest to myers on line counts, and the whole decision is worth about one commit in forty-four. The finding worth carrying away is the other one: minimal did not change a single byte across 800 commits while being documented as slower, so if it is set in your config it is pure cost. Check that before you tune anything else, and then go and argue about something that affects more than 2.5 percent of your work.
Sources