You open a pull request. You changed one line. The diff is 412 lines.
You blame the linter, then yourself. Usually it's neither. A diff compares characters before it compares meaning, and the characters that changed are invisible.
1. Line endings: CRLF vs LF
The classic culprit. A file written on Linux ends its lines with \n; a file written on Windows ends them with \r\n. Git stores bytes, so the moment a teammate's editor (or a script, or a Windows tool) rewrites the file with the other convention, every single line differs by one byte you cannot see.
To confirm it, run git diff --ignore-cr-at-eol. If the 412-line diff collapses to your one real change, that's your answer. When the two versions are not in git yet — two config files, two API response dumps — I paste both into the Diff Checker and flip the "ignore whitespace" toggle. It runs entirely in the browser, so pasting a private config is not a concern.
2. Trailing whitespace
Editors with "trim trailing whitespace on save" enabled rewrite every line they touch, and any formatter run rewrites the whole file. You get lines marked as changed that look byte-identical, because the difference sits at the end, past where your eye stops rendering.
3. Tabs vs spaces, and indent conversion
One contributor's editor converts indentation on save. Every nested block now reads as "modified". git diff -w (ignore all whitespace) collapses it instantly — and if it does, you know the change is cosmetic.
4. Encoding and BOM
A BOM added by a Windows editor, or a latin-1 → UTF-8 rewrite, changes every line containing a non-ASCII character. file on both versions tells you the encoding, and a suspiciously huge git diff --stat on a mostly-ASCII file is the hint.
The habit that fixes it permanently
-
.gitattributeswith* text=auto eol=lfnormalizes line endings at commit time, once, for everyone. -
.editorconfigwithend_of_line = lf,insert_final_newline = true,trim_trailing_whitespace = trueso every editor agrees on the rules. - Review with
git diff -wbefore you push. If the diff disappears, the change is whitespace-only: revert it or commit it on its own, so the real change stays reviewable.
A diff never lies — it compares characters. When its report looks impossible, check the invisible ones first: end-of-line bytes, trailing spaces, indentation, encoding. A whitespace-aware diff view is the fastest way to stop guessing and get back to your actual change.
Top comments (0)