How diffing works
Comparing two texts means finding the smallest set of changes that turns one into the other. Formally this is the longest common subsequence problem: find the longest sequence of lines appearing in both, in order, and everything outside it is an addition or deletion.
The classic algorithm is Myers' diff, published in 1986 and still the basis of Git's implementation. It finds a minimal edit script efficiently by searching a graph of possible edit paths.
This tool compares line by line, which is the granularity most useful for code, configuration, and structured text.
Line, word, and character granularity
Different comparison levels suit different content.
Line-level is standard for code. Programming languages are line-oriented, and a changed line is usually the meaningful unit. Its weakness is that changing one word marks the whole line as changed.
Word-level suits prose, where a paragraph is one long line and line diffing would flag the entire paragraph for a single typo fix. Most document comparison tools work this way.
Character-level is precise but produces noisy output on anything substantial. It is most useful within a line, which is why many tools combine approaches: line diff first, then character diff within changed lines.
Whitespace, the noisiest problem
Whitespace differences produce diffs that are technically correct and practically useless.
Line endings are the biggest culprit. Windows uses CRLF and Unix uses LF, so a file edited on both platforms can appear entirely rewritten. Git's core.autocrlf setting and a .gitattributes file are the usual fix.
Trailing whitespace is invisible but compares as different. Most editors can strip it on save, and doing so avoids the problem entirely.
Tabs versus spaces and indentation changes flag lines that are semantically identical.
Git offers -w to ignore all whitespace and -b to ignore changes in amount. Both are useful when reviewing a reformatting commit.
Reading a unified diff
The standard format shows changes with a few lines of surrounding context:
---and+++identify the old and new files@@ -12,7 +12,9 @@is a hunk header: from line 12, 7 lines in the original become 9 in the new- Lines beginning with
-were removed - Lines beginning with
+were added - Lines beginning with a space are unchanged context
A modified line appears as a removal immediately followed by an addition, since a line-based diff has no concept of modification.
Practical advice for cleaner diffs
Separate formatting from logic. A commit that reformats and changes behaviour is nearly impossible to review. Do them separately.
Configure a diff tool for structured data. Reformatting JSON or XML before comparing removes noise from irrelevant whitespace and key ordering.
Keep lines reasonably short in prose. One sentence per line in Markdown produces far more readable diffs than reflowed paragraphs, where a single edit rewraps everything.
Use git diff --word-diff for documentation changes. It highlights the changed words within a line rather than flagging the whole line.
Frequently asked questions
What algorithm do diff tools use?
Most use Myers' diff algorithm, published in 1986, which finds a minimal edit script by solving the longest common subsequence problem. Git still uses it by default.
Why does my diff show the entire file as changed?
Almost always line endings - Windows CRLF versus Unix LF. Configure Git's core.autocrlf setting or add a .gitattributes file to normalise them.
What is the difference between line and word diffing?
Line diffing flags a whole line when anything in it changes, which suits code. Word diffing highlights the specific words that changed, which suits prose where a paragraph is one long line.
How do I ignore whitespace in a diff?
Use git diff -w to ignore all whitespace or -b to ignore changes in the amount. Both are useful when reviewing a reformatting commit.