docs(gap-baseline): retract false main-history-splice claim (shallow-clone artifact) - #1722
docs(gap-baseline): retract false main-history-splice claim (shallow-clone artifact)#1722seonghobae wants to merge 11 commits into
Conversation
A triage pass on 15 of the repo's stalest open PRs found every one produces "fatal: refusing to merge unrelated histories" against origin/main -- not an ordinary merge conflict. Independently verified: main now has multiple historical roots, with the splice landing roughly 2026-08-20/21 (PR bases before that window are not ancestors of current main; bases after it are). This changes how future triage on this repo's PR backlog must proceed: check base-SHA ancestry (git merge-base --is-ancestor <base> origin/main) before attempting the standard merge-and-resolve recipe on any PR older than ~2026-08-20/21, since a large fraction of the ~100+ remaining open PRs are likely on the orphaned side and will hit the identical wall. Records the discovery, scope, and recommended per-PR path (re-verify against current main, then re-implement as a fresh branch if still needed) rather than a mechanical fix, since none was safely available. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…clone artifact) The 2026-09-02 "main's history was spliced ~2026-08-20/21" entry was wrong. The local .github checkout in the analysis sandbox was a shallow clone (git rev-parse --is-shallow-repository -> true); a shallow clone's truncation-boundary commits present as disjoint history roots, and git merge from inside one genuinely raises "fatal: refusing to merge unrelated histories" even when the real, full history is a single connected line. After git fetch --unshallow, origin/main has exactly one root commit and 731af58 (claimed unreachable) is a normal ancestor. A Devin Review comment on this PR directly disputed the original claim and prompted the re-check that found the real cause. Retraction comments were posted on all 16 PRs that received the false triage guidance (15 from the original pass plus one from a second triage pass that was stopped before it could post more); no merges or pushes were ever made on the basis of the false diagnosis. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
…, not 17) Devin Review caught an internal inconsistency: the entry said "17 open PRs" but listed and later referenced 16. Corrected the count and clarified that the two queued-but-unposted PRs (#1147, #1009) never received a comment and need no retraction reply. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
…n-history-splice # Conflicts: # docs/product-technical-gap-baseline.md
Evidence log — 2026-09-02Exact current head:
Gate decision: HOLD. The focused test evidence is positive, but it does not substitute for terminal exact-head required/security/provenance checks. No merge should occur until those checks complete and the live protected-branch/review gates are satisfied. |
|
Scheduled review-feedback autofix for this PR head.
|
…n-history-splice # Conflicts: # docs/product-technical-gap-baseline.md
|
The Generated by Claude Code |
…n-history-splice-merge
|
Merged current Generated by Claude Code |
Both found by an adversarial re-triage of this session's own open PRs, where the classifier made the first error itself -- which is the evidence that the entry is needed. cancelled is not failure. On #933, 22 check runs on head 9988c4f were all completed: 20 cancelled, 2 skipped, ZERO failure, with the combined commit status reading success. An automated triage pass still labelled it CI-red and produced a careful analysis of whose fault a failure was that did not exist. Org-wide the cancelled case dominates -- 18 of the 20 most recent agent-review-runtime-quality-ci.yml runs were cancelled -- so reading the conclusion field rather than the surrounding noise is the whole discipline. The starvation loop is the second half. A bot auto-merging main into a branch on a cadence, against the saturated queue of signature 7, means no check can ever conclude: each new head cancels the runs still queued from the last one. On #1722 opencode-agent[bot] merged main in four times across three days; per-head outcomes were cancelled, failure, failure, cancelled, pending, and run 33945594764 sat queued 4.5 hours without ever executing before the next auto-update killed it. That PR has not completed a check cycle once. Consequences recorded: never tell anyone to wait on a specific queued run id, because on an auto-updated branch it may already be cancelled and a cancelled run cannot produce a conclusion; and do not merge main in yourself in response, since a second updater cannot help a branch already updated faster than the queue absorbs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
Retraction
This PR originally claimed
main's history was spliced onto new roots around 2026-08-20/21, based on 15 PRs (later 16, plus 2 more queued) all hittingfatal: refusing to merge unrelated histories. That claim was wrong.Root cause: the local
.githubcheckout in the analysis sandbox was a shallow git clone (git rev-parse --is-shallow-repository→true). A shallow clone's truncation-boundary commits present as disjoint history roots (git rev-list --max-parents=0lists them as fake roots), andgit mergefrom inside a shallow checkout genuinely raisesfatal: refusing to merge unrelated historieseven when the real, full history is a single connected line — this is real, documented git behavior for shallow clones, which is exactly why it read as convincing evidence of an actual split.After
git fetch --unshallow origin:origin/mainhas exactly one root commit (0c6e99ed0acab17b1cdd9f853a8398ddb0eed269), and731af58e(originally claimed "not reachable from currentmainat all") is a completely normal ancestor.A Devin Review comment on this PR directly disputed the original claim ("All 15 listed heads share a merge base with current
main, and731af58eis its ancestor") and asked for reproducible evidence — that's what prompted the re-check that found the shallow clone. Thank you for catching this.Corrective actions taken
docs/product-technical-gap-baseline.md's entry has been rewritten in place to record the retraction, the real root cause, and a standing lesson: always checkgit rev-parse --is-shallow-repository(andgit fetch --unshallowif true) before diagnosing any multi-root or "unrelated histories" condition on any repo in this ecosystem.Verification
pytest tests/test_product_technical_gap_baseline.py -q→ 5 passed.🤖 Generated with Claude Code
https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
Generated by Claude Code