Why gate a merge on new-code (diff) coverage instead of the whole repository's global percentage?

### The problem a global percentage has A global coverage percentage is a ratio over the whole codebase. In any repository with history, the denominator is enormous and almost entirely legacy, so the number is dominated by code nobody is touching this quarter. That has two consequences, and both of them break the number as a merge gate. First, it is **insensitive**. Take the fare calculator repository: roughly 78,000 measurable lines, currently at 91.4% overall. A change that adds 240 lines of new zone-pricing logic with not a single case behind it drops the global figure by about three-tenths of a percentage point. If the gate is "do not fall below 90%", the change sails through. The signal from the change is drowned by the mass of everything else. Second, it is **unfair and unactionable**. If the repository sits at 61% and the policy says 80%, an engineer fixing a two-line defect is told the build fails for a debt they did not create and cannot repay in this change. The rational response is to disable the gate, request an exemption, or write cheap cases against whatever is easiest to cover — which is never the risky code. ### What diff coverage measures instead New-code or diff coverage restricts the ratio to the lines this change added or modified. The denominator becomes the change itself, so the signal scales with the change rather than with the repository: - **Proportional.** Two hundred and forty new uncovered lines read as 0% on the change, not as a rounding error. - **Actionable.** The report points at lines the author just wrote and can still remember. The fix is obvious and local. - **Fair on legacy.** A newcomer to an under-covered repository is asked to leave their own change tested, not to repay decades of debt. - **Convergent.** Because every change now arrives covered, the global figure rises as a **consequence** rather than as a target — which is exactly the relationship that avoids gaming. The usual policy shape is a floor on the changed lines (something like 78% or 80% on the diff, not 100%, so that a genuinely untestable line does not block the change) plus a minimum-lines rule so that one-line changes are not judged on a sample of one. ### Pairing it with a ratchet Diff coverage governs new work; a **ratchet** protects what exists. Record the current global figure as a floor and fail the build if a run comes in below it; when a run comes in above, raise the floor to the new value. The number can then only move upward, without anyone having to pick an aspirational target that the codebase is years away from and that everyone therefore ignores. Two practicalities. Give the floor a small tolerance — a percentage point or so — or ordinary churn produces failures that have nothing to do with the change. And provide a documented override, because legitimate work lowers the figure: deleting a heavily covered module, or absorbing a large third-party file, moves the ratio for reasons no case can fix. ### What diff coverage does not tell you It is a better gate, not a good measure of quality, and a strong answer says so. - It inherits the whole assertion problem. A change can hit 100% on its own lines with cases that check nothing. - It says nothing about the **effect** of the change on code it did not touch. A one-line change to a shared rounding helper can break the fare boundary in a module whose lines are untouched and therefore unmeasured. - Refactors read badly. Moving 600 lines between files marks them all as changed, so a pure move can show poor diff coverage with no behaviour added at all — a case for review-and-override, not for writing cases to satisfy the gate. - It is gameable in its own way: split the risky lines into a change small enough to fall under the minimum-lines rule, or pad a change with trivially covered lines to lift the ratio. ### The interview shape The answer an interviewer is listening for is the sensitivity argument first — the global number cannot detect a change because the denominator is the whole repository — then actionability and fairness, then the ratchet as the complement, then an honest limitation. A candidate who presents diff coverage as a fix for the assertion problem has swapped one misplaced trust for another. It fixes **where** you point the measurement, not **what** the measurement can see.