Repository navigation
Conversation
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
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 |
Resolved via the updated fix/merge-closed-while-polling (which already contains origin/main). retarget_pr now reuses main's set_pr_base, and the README describes the retarget against main's rewritten stacking paragraph (children target their parent's branch with or without --stack). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015rnEEjXWDBdePRhKMmZr1w
…-base Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015rnEEjXWDBdePRhKMmZr1w
|
This change is already in Generated by Claude Code |
Summary
With
--stack, child PRs are opened against their parent's split branch.mergemerged them as-is, relying on GitHub to retarget children once the parent's head branch is deleted — butgh pr merge --autoskips the head-branch deletion, and GitHub only deletes it itself when "Automatically delete head branches" is on (off by default). Sosplit --stack+merge --automerged every child into its parent's branch and reported success whilemainnever received them (reproduced with a recording fakegh:pr-2 into pr-split/dev/pr-1,pr-3 into …/pr-2,Merged (6), exit 0).merge_allnow derives the stacked children from the plan's branch records (base_branch ≠ plan base) and, right beforemerge_pr— i.e. onceiter_readyand the unmerged-parent guard guarantee the parent merged — calls a newretarget_pr(gh pr edit N --base <plan base>). GitHub refuses that edit for PRs in a native stack ("part of a stack"), which is tolerated with an info log because GitHub retargets those itself. Merge nodes already target the base and are untouched. README's stacking andmergeparagraphs now describe this instead of the old (false) "GitHub retargets children automatically".Stacked on #103 (stack #99 = #67→#98→#103→this), which owns the merge-loop changes.
Test plan
TestStackedMergeRetargetsBase: child retargeted at the plan base before merging; unstacked PRs untouched;--autoretargets before queueing — all fail on the baseTestRetargetPr: edits the base; native-stack refusal tolerated; other failures raiseghscenario: every merge now recordsbase=main