Read the diff as an attack surface, not a summary

Read a diff the way you read untrusted input: as a representation someone chose to show you, made by a tool with defaults, cut by pipes, sized to be skimmed. Apply nothing until the tree confirms the story. This assumes you can already skills/verifying-a-claim; every check below is that shape.

Inspect the shape before any hunk

Run git diff --stat and git apply --numstat before reading lines. The file list is the contract; the hunks are prose. A "small refactor" touching lock.txt, a workflow file, or anything unstated is a different change wearing this change's clothes. Generated files (vendored deps, minified JS, lockfiles) hide the two real lines — dismiss them by name, deliberately, not by eye.

Where the format lies

Most of this is in the git-apply and diff-format man pages, in passing. The claims below were verified against git 2.54.0 on 2026-09-10.

Context is three lines. A hunk shows ~3 lines around each change plus a function name in the @@ header. That name is a regex you can redefine per language (gitattributes' hunk-header); it can name the wrong construct. Code four lines off the changed line is invisible. Read the whole file post-apply, not the hunks.

Whitespace flags delete meaning. git diff -w collapsed a change of Python indentation (return moving a nested block) to a zero-line diff. Indent is control flow in some languages, and in any language -w/--ignore-space-change is a claim that the whitespace change is noise — made by whoever ran the command, not by you. Review whitespace changes as content.

Renames are a threshold, and mode changes are a line you skim past. Rename detection reports a similarity index — below threshold, a moved-and-edited file renders as delete-plus-new-file and its whole history detaches from your view. And old mode 100644 / new mode 100755 is a real change with no hunks at all: a script made executable, a setuid bit. Grep the raw patch for mode and rename rather than trusting the stat.

Moved code hides changed code. The diff algorithm pairs identical lines, so a block that moved and got edited in passing can render as pure additions in the new location — no - lines, nothing to react to. --color-moved exists because this is common enough to need highlighting.

Truncated hunks are valid patches. Cut a two-file patch just before the second diff --git line and git apply succeeds, rc=0, having silently not made the second file's change. Anything piped through head, less, or a context-overflowing agent transcript is a different diff from the one on disk. Compare --numstat output of the patch file against the patch you were shown; count diff --git lines.

Hunk counts are trusted, not checked. Tamper a number in @@ -1,3 +1,3 @@ and git apply says corrupt patch (rc=128); --recount exists for patches hand-edited without adjusting counts. Needing --recount is itself a signal: someone edited the patch.

When not to apply

• git apply --check (ideally with --3way, so the index blob hashes in the index line get verified, not just the text) fails or was not run. A check you skipped has unknown, not clean, state.
• The patch touches paths outside the working tree. git rejects this by default and calls the override --unsafe-paths; the name is the warning.
• The diff was written by the thing that wants it applied. Diff the tree (git diff HEAD on a scratch apply), never the artifact you were handed. The man page warns a patch that renames a→b and b→a corrupts files if applied file-by-file — ordering is part of what you cannot see.
• git apply --reject was needed. Partial application is not the change.

The pair

Your reading and a scanner disagree in opposite directions — you see intent and miss the glob of moved code that added a dependency; it sees the shape and misses the sentence that redefined the word "trusted". Do not average them. skills/review-and-scanner-fail-opposite shows which one to believe per finding.

Sources: git-apply and diff-format man pages (git-scm.com), and demos on git 2.54.0 (truncation, recount, -w-erases-indent, mode changes), all 2026-09-10; HN threads 47169518 and 48980193 on reviewer fatigue with agent-authored diffs, 2026-09-10.