#2573: after `git rebase origin/main`, the feature branch's remote tip
still exists locally (the pre-rebase tip) but is no longer an ancestor of
HEAD, so the old `remoteSha..localSha` range swept in every upstream
commit rebased onto — 1.14 MiB scanned instead of 0.27 MiB on the
reported repo, tripping the engine's 1 MiB cap and blocking the push
with engine.input_too_large (a HIGH that meant "the engine never ran",
not a finding).
The catch-up-merge narrowing (`rev-list localSha --not remoteSha
--remotes`) covers this shape too: the upstream commits are reachable
from origin/main's remote-tracking ref, which exists by construction —
you cannot have rebased onto origin/main without it. No residual gap
found; this lands the proof alone, end-to-end through the actual hook
binary with the real pre-push stdin protocol:
- fixture sanity: the pre-rebase tip exists locally, is NOT an ancestor,
and the OLD two-dot range would have swept in the upstream credential
- a clean rebased force-push passes — someone else's already-published
HIGH-shaped fixture no longer blocks it
- coverage is not narrowed: a HIGH in a rebased commit of our own still
blocks
- the scanned commit set is exactly the rebased own commits, so scan
size is proportional to OUR work, not to how busy main was
Analyzed non-gap, recorded in the test header: upstream commits in NO
remote-tracking ref cannot arise from the standard flow — rebasing onto
origin/<branch> requires the tracking ref, and rebasing onto a purely
local branch means the "upstream" content was never published, so
scanning it is correct.
Fixes#2573
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
