fix(repo-audit): a rebase-merged branch is not unmerged work (0.1.0-alpha.16) - #46
Conversation
Found by dogfooding `anvil repo audit` on Anvil itself: eleven findings, eight of them GIT_BRANCH_NOT_ON_DEFAULT, and seven of those eight branches were fully merged. Rebase and squash merges both rewrite SHAs, so ancestry calls landed work unmerged forever — the failure mode my own standing notes describe and my own check reproduced. `git cherry` compares patch ids instead of SHAs. Measured on all eight branches before writing anything: 7 merged branches ahead>0, cherry-unapplied=0 noise 1 real branch ahead=1, cherry-unapplied=1 genuine The finding now gates on unapplied commits rather than ahead-count, and reports "N commit(s) with no equivalent on main". Anvil's own audit goes 11 findings -> 5, with the one genuinely unmerged branch still reported. Known limit, stated rather than papered over: `git cherry` matches patch ids one-for-one, so a branch of N commits squashed into a single patch still reads as unapplied. It fails toward reporting, which is the safe direction. Rebase merges and 1:1 squashes — this repo's whole history — are covered. `cherry` is added to the read-only allowlist; it only reads. Also adds the none-exist unit test for the emptiness split introduced in alpha.15. All-exempt was covered directly; no-governance-files-at-all was covered only indirectly by a golden fixture, and it is the branch that would silently launder a missing rule surface into a date-hygiene pass. One fixture note worth keeping: the first version of the rebase test cherry-picked straight onto an unmoved main and produced the IDENTICAL sha — same tree, parent, author and timestamp — so nothing diverged and the test asserted nothing. It now moves main first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (13)
Comment |
1 participant
Nothing in your last brief is wrong — the one thing you asked me to confirm is answered below, and the rest of the round went to work I found by dogfooding.
Confirming §3: the all-exempt case was covered, the other half wasn't
You were right that all-exempt is covered directly. But the emptiness split I added in alpha.15 has two branches, and no-governance-files-at-all was covered only indirectly, by a golden fixture. That's the branch that would silently launder a missing rule surface into a date-hygiene pass. Now has its own unit test.
alpha.16: my own check was producing 7 false positives on Anvil
anvil repo auditon Anvil reported 11 findings — 8GIT_BRANCH_NOT_ON_DEFAULT, of which 7 branches were fully merged. Rebase and squash merges rewrite SHAs, so ancestry calls landed work unmerged forever. My own standing notes describe this failure mode; my own check reproduced it.Measured on all 8 branches before writing anything:
fix/publish-root-cause-commentgit cherrycompares patch ids rather than SHAs and separates them cleanly. n=8, not n=1.The finding now gates on unapplied commits and reports "N commit(s) with no equivalent on
main". Anvil's own audit: 11 findings → 5, with the genuinely unmerged branch still reported.Known limit, stated rather than papered over:
git cherrymatches patch ids one-for-one, so N commits squashed into a single patch still read as unapplied. It fails toward reporting, which is the safe direction. Rebase merges and 1:1 squashes — this repo's entire history — are covered.cherryis added to the read-only allowlist; it only reads.Fixture note
The first version of the rebase test cherry-picked onto an unmoved
mainand produced the identical SHA — same tree, parent, author, timestamp — so nothing diverged and the test asserted nothing. It now movesmainfirst. Same family as the earlier silent-tool-failure catches.Verify
lint · format:check · release:pin --check · typecheck · 520 pass / 0 fail · verify:self-audit-proof.
🤖 Generated with Claude Code