Diff Checker

Nothing changed, yet the whole file is red

You open a pull request for a one-line fix and the review screen shows 340 deletions and 340 insertions. You read the file top to bottom and nothing is actually different. Everyone who has seen this screen reaches the same conclusion at the same speed: the change is real, it is just made of characters that do not render.

Two causes account for almost every instance. Either the line-ending convention changed, or an editor stripped trailing whitespace on save. Neither leaves a visible mark, and both touch every line in the file.

Line endings, the CRLF and LF problem

Windows terminates a line with two characters, carriage return and line feed, written \r\n. Linux and macOS use a single \n. A colleague who opens a file on Windows and saves it without typing anything adds one invisible \r to every line, and as far as version control is concerned every line is now different.

1# The review shows no visible difference, but Git counts the file as modified2$ git diff --stat3 src/utils/format.ts | 340 ++++++++++++++++-----------------4 5# Make the hidden characters visible:6$ cat -A src/utils/format.ts | head -27export function slugify(input: string) {^M$8  return input.trim();^M$9#                    ^^^ CRLF ending             ^^^ a plain LF would show only $10 11# The durable fix lives in the repository, not in one developer's config:12$ echo "* text=auto eol=lf" > .gitattributes13$ git add --renormalize .

git config core.autocrlf is a per-machine patch. It works for you and does nothing for the next person who clones the repository, which is why the same argument resurfaces every few months. A committed .gitattributes applies to everyone and settles it once.

You will not see line-ending noise in this tool. Before either side is split into lines, \r\n and standalone \r are folded to \n, and a trailing newline is not allowed to invent a phantom empty final line. Paste one side from a Windows machine and the other from a Unix one and the comparison still reflects the content.

Why a moved block shows up twice

The comparison runs on a longest common subsequence. The engine takes the lines from both sides and finds the longest sequence that appears in both while preserving order. Anything in that sequence is unchanged; everything else is a deletion or an insertion. Order is the only rule it enforces.

Move a function from the bottom of a file to the top and its lines can no longer be part of a common subsequence, because taking them would break the ordering. The result is a deletion where the block used to be and an insertion where it now lives. That is not a shortcoming to be fixed, it is what a line-oriented diff means, and it is why "this block only moved" is a comment a human has to write.

Trailing whitespace and character-level detail

Trailing whitespace is the second great source of review noise. Many teams enable "trim trailing whitespace on save" precisely because of it, and the pain arrives when only half the team has it enabled: the moment one of them opens an old file, lines nobody touched show as modified. Agreeing on the setting matters more than which way you agree.

To silence whitespace differences for one comparison, use the ignore-whitespace option. It collapses runs of whitespace and trims the ends, but only for matching purposes. Every row you see on screen carries the original text, never the normalized form, because showing someone a document they did not write is worse than showing them noise.

Knowing which line changed is often not enough. When one word changes inside a long sentence, the line diff gives you a red row and a green row and leaves you to spot the difference by eye. The inline view splits that line into words and the whitespace between them and runs the same alignment again, so the single changed word is highlighted directly. Tokenization keeps combining marks attached to their base letter, which is what stops accented text from being sliced into individual characters.

Two identical-looking strings that are not equal

Unicode allows one letter to be written two ways. The letter "ğ" can be a single code point, or it can be "g" followed by a combining breve. On screen the two are indistinguishable; in the file they are different bytes. The single-code-point form is called composed (NFC) and the multi-code-point form decomposed (NFD).

This engine deliberately never calls normalize(). Normalizing would hide the difference, and hiding it means you never learn that your data has a real problem. If two lines look identical here and still compare as different, the same mismatch is very likely breaking your search, your sorting and your deduplication somewhere else. The fix belongs at the source, by normalizing on write, not in the tool that reported it.