This is Part 6 of AI Grew Up on Git, a series on the Git infrastructure that raised AI and what AI is now doing to it.
Every part of this series so far has been a story about Git’s tamper-evident history getting stretched over something it was never built for. A social layer for strangers. A home for gigabyte-sized weights. A record of scientific claims. A $7.5 billion acquisition. The strain has a precise technical cause, and it deserves a full look on its own terms.
Git’s whole value, since Part 1, rests on one promise: any two points in its history can be compared, honestly, by anyone, and the comparison will tell you exactly what changed. For one specific kind of file, that promise quietly stops applying. Not because the file is inconvenient. Because the question “what changed” stops having a stable answer.
What Diff Does
Start with the tool itself, because the failure only makes sense once the mechanism is precise.
Git’s diff traces back to a 1986 paper by Eugene Myers in the journal Algorithmica. Myers took two old, separately known problems, finding the longest stretch two sequences have in common, and finding the shortest set of edits to turn one sequence into the other, and showed they were the same problem in disguise. Both could be modeled as finding the shortest path across a grid, an “edit graph,” and he gave a fast way to search that grid. That search is what runs, in some refined form, every time you type git diff.
The algorithm operates on sequences, and by convention, Git feeds it sequences of lines. Each line of a text file becomes one unit to compare, which is why a single changed line shows up in a diff as one deletion and one insertion rather than a “modification.” There is no concept of an edited line in this output, only lines that vanished and lines that appeared to replace them. This line-by-line habit is a choice about what to feed the algorithm, not a limit built into the algorithm itself, and Git can rerun the same logic at the level of words or characters when you ask it to.
On a binary file, none of this runs. Git checks for line structure, finds none, and rather than attempting a comparison it cannot make sense of, it prints two words and stops: “Binary files differ.” That message is not a failed diff. It is Git declining to try.
One precision matters here, because the rest of this argument depends on it: Git is not incapable of comparing bytes. A flag, git diff --binary, produces a genuine byte-level patch, encoded so it can be transmitted and reapplied. The capability exists. What matters is what happens once you have that comparison in hand for a specific kind of file, and discover it told you nothing true.
