Diff Summariser Input Builder
Trim a unified diff to what a reviewing model needs — fewer context lines, no lockfiles, no whitespace-only hunks — and get a diff that still applies.
1 file(s) of 2 read, 7 changed lines. The output is still a unified diff with recomputed @@ headers — git apply --check will accept it against the same base.
- Diff lines in
- 33
- Diff lines out
- 20
- Reduction
- 39%
- Files removed
- 1
- Characters out
- 493
- package-lock.json — matched "package-lock.json" (1 hunk(s), 7 lines)
Handing a whole pull request to a model is expensive and usually worse than handing it a third of one. The diff of a real change is mostly lockfile churn, generated output, import reordering and the three hundred lines of context git includes so a human can scroll. None of it changes the review, and all of it competes for attention with the fifteen lines that do.
Why the hunk headers matter
Every tool that trims a diff has to decide what to do about the @@ -12,7 +12,9 @@ line, and the wrong answer — leave it — produces something that looks like a diff and is not. The counts no longer match the lines, so git apply refuses it and any model reasoning about line numbers is reasoning about the wrong ones. This page recomputes both starts and both counts from the lines that survived, which is also why removing an interior stretch of context splits the hunk in two instead of leaving a hole.
Dropping whole files rather than parts
When the budget bites, whole files go. It is tempting to trim every file a little instead, and it is a trap: a reviewer model shown two thirds of a change will review those two thirds with complete confidence and never mention that something is missing. A file that is absent from the diff is at least visibly absent — and the list under the output names every one, so you can put it back or review it separately.
What it still cannot know
A diff is a poor description of a change. It does not carry the code around the change, the callers of the function you renamed, or the test that covers it — so a reviewer model reading only this will miss the bug that lives in the interaction between the diff and the rest of the file. Turning the context up helps a little; adding the whole changed files helps more and costs more. This tool makes the cheap version as good as it can be, not the good version cheap.