Text Diff: How Comparison Works & Reading Output

Q: How do merge conflicts relate to diffs?

A 3-way merge diffs both branches against their common ANCESTOR: changes in different regions merge automatically; overlapping edits produce conflict markers: >>>>>> branch. Resolution = choosing/editing between markers, deleting the marker lines, then committing. The markers are plain text in YOUR file — search for <<<< before committing; shipping conflict markers to production is a rite of passage best avoided.

Q: What mistakes happen with diffs?

(1) Comparing files with different line endings (CRLF vs LF — every line "changes": configure .gitattributes/core.autocrlf); (2) whitespace-only churn drowning real changes (diff -w / hide-whitespace settings); (3) trusting minimal diff as semantic truth (moved blocks read as del+add); (4) binary files in diff workflows (images/fonts show "Binary files differ" — no line granularity); (5) applying patches to drifted versions without checking rejects; (6) committing <<<< markers; (7) reviewing huge diffs raw — split commits; the human reviewer is the bottleneck of the whole pipeline.

Aspect

Detail

Algorithm

LCS via dynamic programming, O(n×m)

Granularity

Whole lines (git-style unified view)

Limit

600 lines per side to keep DP fast

Colors

Green = added, red = removed (strikethrough)

Text Diff: How Comparison Works & Reading Output

Updated 2026.08.01~3 min read

Diff finds line-level changes between texts: unified format shows −removed +added with @@ hunks of context. Myers algorithm minimizes the edit script. Uses: code review, config drift, contract versions. Includes word-level diff, patch application and merge-conflict anatomy.

Key Takeaways

Unified format: − old line, + new line, space = context; @@ -1,4 +1,5 @@ = hunk location

Algorithm: Myers finds the minimal edit script (longest common subsequence dual)

Granularity: line diff for code, word/char diff for prose

Conflict markers: <<<<<<< yours ======= theirs >>>>>>> = manual merge needed

Core answer: A diff shows the minimal line-level changes between two texts: − lines removed, + lines added, unchanged lines as context. Unified diff format (diff -u) with 3 lines of context is the standard; git calls it a "patch". Two files differing in one line show ~7 lines of output (hunk header + context + the change). Diffs work line-by-line, so reflowed paragraphs look fully rewritten — normalize formatting before diffing prose.

Reading a unified diff

@@ -3,7 +3,7 @@ means: from old file line 3, show 7 lines; new file line 3, 7 lines. Lines prefixed " " are context, "−" old-only, "+" new-only. One hunk per changed region; distant changes get separate hunks.

The algorithms under the hood

Myers algorithm (git default): finds the shortest edit script — minimal insertions/deletions. O(ND) time, which is why huge files diff slowly.
Histogram/patience (git options): better on code with repeated lines (braces); often produces more intuitive hunks.
Word/char diff: same algorithms on word or character tokens — what "git diff --word-diff" and online text-compare tools use.

Worked examples

Example 1 — Code review. A PR showing +127 −3 with 120 lines being an auto-formatter: ask to split format-only changes from logic changes, or review with "hide whitespace" (GitHub's w=1).

Example 2 — Config drift. Production nginx.conf vs repo version: diff reveals a manually added client_max_body_size 50m that never made it to git — the classic snowflake-server catch.

Example 3 — Contract comparison. Two versions of a contract, word-diffed: one changed "shall" to "may" — a single word worth millions; character-level diff catches what eyes skim past.

Example 4 — Merge conflicts. Conflict markers <<<<<<< / ======= / >>>>>>> show YOUR side vs THEIR side of the same lines; resolve by editing to the intended final state, then deleting all markers.

Common mistakes and myths

Diffing minified/generated files — bundle.js diffs are noise; add generated files to .gitignore or mark them linguist-generated.
Whitespace wars — mixed tabs/spaces or CRLF/LF make every line "changed"; standardize via .gitattributes + editorconfig before mass commits.
Trusting line-diff for prose — one reflowed paragraph diffs as 100% changed; use word-diff for documents.
Assuming diff = semantic — two programs with identical diffs can behave differently (moved code across scopes); diff shows text, not meaning.
Binary blindness — diff can't show image/XLSX changes; use specialized tools (image diff overlays, spreadsheet comparators) or accept "files differ".

Frequently Asked Questions

How do I read unified diff output?

Header: --- a/file and +++ b/file. Hunk header @@ -10,6 +10,7 @@ = starting line 10, 6 old lines shown, 7 new. Body: space-prefixed = unchanged context, − = present only in old, + = present only in new. A changed line appears as a −/+ pair; pure additions show only +. Green/red highlighting in tools maps to +/−. Read hunks top-down; unchanged regions between hunks are elided.

How does the diff algorithm decide what changed?

Myers (1986) models it as shortest edit path: find the minimal sequence of insertions/deletions transforming A into B — equivalent to the longest common subsequence. Greedy exploration with linear space tricks makes it fast even on large files. Consequence: diffs are MINIMAL but not always INTUITIVE — the algorithm may match blank lines oddly or attribute a moved block as delete+insert rather than "move."

Line diff vs word diff — when to use which?

Line-level: code, configs, structured text — the git default; a one-word change marks the whole line. Word/char-level: prose, contracts, documentation — highlights exactly "shall → may" inside a paragraph. Tools: git diff --word-diff, --color-words, or this page's inline mode. For prose review, word diff is the difference between spotting the comma that changed liability and missing it.

What is a patch and how is it applied?

A patch is a diff saved as a file — a portable set of changes. Apply: patch < fix.diff or git apply fix.diff. It works contextually: matches the surrounding lines, tolerates position drift, fails ("rejects") when context no longer matches — producing .rej files for manual fixing. This 50-year-old mechanism still ships the Linux kernel via mailing lists.

How do merge conflicts relate to diffs?

A 3-way merge diffs both branches against their common ANCESTOR: changes in different regions merge automatically; overlapping edits produce conflict markers: <<<<<<< HEAD (your version) ======= (incoming) >>>>>>> branch. Resolution = choosing/editing between markers, deleting the marker lines, then committing. The markers are plain text in YOUR file — search for <<<< before committing; shipping conflict markers to production is a rite of passage best avoided.

What mistakes happen with diffs?

(1) Comparing files with different line endings (CRLF vs LF — every line "changes": configure .gitattributes/core.autocrlf); (2) whitespace-only churn drowning real changes (diff -w / hide-whitespace settings); (3) trusting minimal diff as semantic truth (moved blocks read as del+add); (4) binary files in diff workflows (images/fonts show "Binary files differ" — no line granularity); (5) applying patches to drifted versions without checking rejects; (6) committing <<<< markers; (7) reviewing huge diffs raw — split commits; the human reviewer is the bottleneck of the whole pipeline.