The actual code change was small: a third-party rendering call inside an ad-management plugin needed to fail safely instead of throwing an uncaught exception that could take down the surrounding page render. A try/catch around one call site, maybe ten lines including the log statement. The diff that would have shipped, un-inspected, was 465 lines.
The gap between those two numbers is the whole post. Not the exception guard — that part was routine. What’s worth writing down is the habit that caught the gap before it shipped, because a 465-line diff for a 10-line fix is a specific, recognizable failure mode, and it’s common enough to be worth a name.
How a small fix becomes an unreviewable diff
The file in question had, at some earlier point, drifted from whatever formatting convention the rest of the codebase used — inconsistent quote style, inconsistent spacing around array syntax, the ordinary entropy of a file edited by hand over time without a formatter enforcing consistency. Opening it in an editor with format-on-save enabled, or running a linter’s --fix flag before making the actual change, rewrites the entire file to the canonical style in one pass. The one real change — the exception guard — lands inside that same commit, indistinguishable in the diff from four hundred and fifty-some lines of pure style churn.
Nothing about that is malicious or even obviously wrong in isolation. A formatter doing its job is a good thing. The problem is entirely about what happens next: if that diff goes straight to a commit and a PR, whoever reviews it is being asked to verify a 465-line change, most of which carries zero actual risk and all of which still has to be read, because the ten lines that matter are indistinguishable from the noise around them without doing exactly that reading.
Isolating the real change
The fix here isn’t a tool, it’s a step: before committing, stash the working changes, diff the stashed version against the pre-format state to see what the formatter alone did, then reapply just the logic-relevant hunks on top of the clean baseline.
git stash
git diff HEAD -- path/to/file.php # confirm this is empty — clean baseline
git stash pop
git diff HEAD -- path/to/file.php # now compare against the full 465-line diff
Concretely, that meant re-applying only the try/catch block and its log statement to the unformatted original file, leaving the pre-existing style exactly as it was, rather than committing the formatter’s rewrite alongside the fix. The resulting diff: ten lines. Reviewable in under a minute, and — more importantly — small enough that a reviewer can actually reason about what it does, instead of skimming a wall of whitespace changes and trusting that the real change is in there somewhere.
Why this is worth a deliberate step, not a one-off
The instinct to skip this is understandable: the formatter’s version is objectively better code, and reformatting the file was arguably overdue anyway. Both true, and both irrelevant to whether the fix and the reformat belong in the same diff. They don’t, for a reason that has nothing to do with code quality: a diff’s job, for the person reviewing it, is to communicate risk. A ten-line diff says "here is exactly what changed and why." A 465-line diff that’s 98% cosmetic says nothing useful about risk at all — it forces the reviewer to either read all of it (expensive, and easy to skim past the part that matters) or trust it wholesale (which defeats the point of review).
The reformat isn’t wasted work — it’s just a different, separate change, with its own diff, that can be reviewed on its own terms ("does this match our style guide, does it change any behavior") without being tangled up with a logic fix that has entirely different review criteria ("does this correctly prevent the exception, does it log enough to debug a future occurrence").
The generalizable version
- A diff’s size should be proportional to its actual risk, not inflated by unrelated formatting churn. If a small logic change produces a large diff, that’s a signal to separate concerns before committing, not a fact to route around during review.
git stashplus a diff against the pre-stash state is a fast, low-ceremony way to see exactly what a formatter or linter’s--fixdid, separately from what you changed on purpose.- A formatter-driven reformat is legitimate work — it just belongs in its own commit, reviewed against its own criteria, never bundled with a behavioral change.
- Before committing, check the diff size against your own mental model of "how big should this change be." A mismatch is worth a minute of investigation before it becomes a reviewer’s problem instead of yours.
- This applies identically whether the diff was produced by a human running a formatter manually or an editor’s format-on-save firing automatically — the fix is the same either way, and it’s cheaper the earlier you catch it.