Why Diffing Uses Longest Common Subsequence, Not Just Line Matching
Comparing two versions of text to highlight what changed sounds like it should be simple line-by-line matching, but that naive approach breaks badly the moment lines are inserted or deleted in the middle of a document — every subsequent line shifts position, and a position-based comparison would flag every single line after the insertion point as "changed," even though most of them are actually identical, just shifted.
The Longest Common Subsequence (LCS) algorithm solves this correctly by finding the longest sequence of lines that appear in the same relative order in both versions (not necessarily contiguous or at the same absolute position), then identifying everything outside that shared sequence as a genuine addition or deletion — this is exactly what lets a diff tool correctly show "one line was inserted here" instead of incorrectly claiming twenty subsequent lines all changed.
This is the same underlying algorithm behind git diff and most version control change-tracking — a genuinely different (and much more useful) approach than simple side-by-side line-number comparison, which is why diff output correctly isolates a small, focused change even in a document where a large block of surrounding content shifted position as a result.