fix(redact-prepush): don't re-scan commits a catch-up merge brought in

[Two-Six-Alpha-1115]

The problem

remoteSha..localSha is "everything new on this branch", which is not the same as "everything new to the remote". Merge origin/main into a feature branch and every commit main gained since that branch's last push becomes an added line — content that is already published, already scanned, and not this push's doing.

Two consequences, both observed in practice:

• False HIGH findings. A placeholder connection string in a fixture someone else had already merged blocked an unrelated push as db.url_with_password, telling the operator to rotate a credential over a file they had never touched. A guard that cries wolf on catch-up merges is one people learn to bypass reflexively — which is exactly how a real secret eventually gets through.
• Oversized scans. The SCAN_CHUNK_BYTES comment already records a 1,146,782-byte diff from "a feature branch catching up to a busy main" blowing the engine's 1 MiB cap. Same root cause, treated there as a size problem and solved by slicing. Narrowing the range fixes the size too.

A two-dot range cannot express this: after merging main, neither the remote tip nor the merge-base with main is an ancestor of the other, so no single base excludes both.

The fix

The narrowed range is rev-list localSha --not remoteSha --remotes, with two guards that matter more than the narrowing itself:

remoteSha stays the base. It is what git tells the hook the remote has, and it is authoritative in a way --remotes is not — tracking refs can be absent (fresh clone that never fetched, a remote with no tracking ref) or stale. Using --remotes alone excludes nothing in a repo without them, so every commit ever made reads as "new". That is the same false positive from the other direction, and it is precisely what the existing test only NEW content is scanned (remote..local), not pre-existing catches.

When excluding tracking refs changes nothing, defer to the plain range. Such a push has no catch-up commits, so the existing range already describes it exactly. This keeps every non-catch-up push on the original gitStrict diff path — the one #1946's fail-closed regression test exercises. Without this guard that test still passes, because the new path never invokes git diff and so the test's stub never fires: it would have gone green forever while testing nothing. A narrowing that silently retires a security regression test is a worse trade than the false positives it set out to fix.

Each commit is diffed alone. A merge's combined diff shows only content present in no parent, so a secret introduced while resolving a conflict is still caught, while an ordinary merge contributes nothing. Falls back to the existing range logic for a fresh repo, an absent remote object, or a >500-commit rewrite.

Verification

• 22/22 existing redact-prepush-hook tests pass, including both #1946 fail-closed cases.
• Both new guards proven load-bearing by mutation: dropping the remoteSha base fails 2 tests; dropping the defer-to-plain-range guard fails 1. Restored: 27/27.
• 5 new tests (test/redact-prepush-scan-range.test.ts) build real repositories on disk, because the behaviour under test is the git plumbing — a mocked git would test the mock. They pin both directions: a catch-up merge no longer re-scans published content (and the old two-dot range demonstrably did), and secrets in new commits, in merge resolutions, and in repos with no remote are all still scanned.
• Other redact suites green: redact-pattern-lint 49/49, gstack-config-redact-keys 6/6, browse/proxy-redact 8/8.
• End-to-end against the real hook: a fresh commit containing an AWS key still exits 1 with aws.access_key.

One note for reviewers: --cc is passed explicitly on the per-commit git show, but it is self-documenting rather than load-bearing — git show already defaults to a combined diff for merges, so no test can pin it. The merge-resolution test pins the coverage, not the flag. Called out in a comment there so nobody over-trusts it later.

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[garrytan]

Thank you — this landed in v1.67.0.0 (credited in the CHANGELOG). Closing since the fix is on main. 🙏