Repository navigation
gh stack rebase uses the wrong onto boundary for merged branches #512
Description
Activity
I am running into this repeatedly on a stack of 8 PRs. The effect is that I'm essentially re-resolving the same conflicts multiple times per day, which is making me want to dissolve the stack (it'd be amazing to have a command for that like
graphitedid!).We hit a related root cause for this exact symptom when working inside a
git worktreeafter pruning merged branches (gh stack sync --prune):Reproduction / Root Cause in
git worktree- Suppose
mainis checked out in the primary repository worktree (at an older commitA), while a stack of PRs is worked on inside a linked worktree. - The bottom 4 PRs in the stack are squash-merged into
origin/main(advancingorigin/maintoB), and we rungh stack sync --prunein the stack worktree. - Because
mainis checked out in the primary worktree,gh stackcannot fast-forward localmainand falls back toorigin/mainfor the rebase target:✓ Fetched latest main from origin ⚠ Could not update local main: failed to run git: fatal: cannot force update the branch 'main' used by worktree at '...' Rebasing the stack onto origin/main instead; local main is unchanged. - The bug: Even though
gh stackrebases the first unmerged branch ontoorigin/main(B), when it saves the updated state to.git/worktrees/<name>/gh-stack(and after--prunehas deleted the local refs for the 4 merged branches), it records localmain's stale SHA (A) as bothtrunk.headand the first unmerged branch's"base":"trunk": { "branch": "main", "head": "<stale-local-main-SHA-A>" }, ... { "branch": "first-unmerged-branch", "head": "<rebased-head>", "base": "<stale-local-main-SHA-A>" }
- On the next
gh stack rebase(after another commitClands onorigin/main),gh stackuses"base": "<stale-local-main-SHA-A>"as the upstream boundary (git rebase --onto origin/main <A> first-unmerged-branch), which causes Git to replay all 4 already-squash-merged PR commits (A..B) on top oforigin/main(C), producing immediate conflicts on every merged file.
Suggested Fix
When
gh stackfalls back to rebasing ontoorigin/<trunk>because local<trunk>cannot be updated (e.g., checked out in another worktree), it should recordorigin/<trunk>'s SHA (not the stale local<trunk>ref's SHA) astrunk.headand as the newbasefor the first unmerged branch in.git/gh-stack.- Suppose
Problem
gh stack rebaseuses the local copy of the repository to decide where a merged branch's commits end. If that local copy is stale, it replays commits that were already merged and produces unexpected conflicts. Instead, it should use the head commit which GitHub recorded when merging the PR.Example
Consider the following stack of branches:
main <- A <- B, where:Ahas commitsa1anda2Bhas commitsb1andb2Then do the following:
Aintomain.gh stack rebase.As expected,
gh stack rebasesees thatAwas merged, and rebasesBontomain.To avoid replaying
A's old commits,gh stackmust knowA's last commit (a2, in this case) so that it selects the correct onto-boundary and only rebasesb1andb2. However, instead of looking upA's last commit on GitHub,gh stacklooks it up in the local repository.The local copy can be stale. Say
Awas rebased and force-pushed from another clone, and GitHub mergeda1'anda2'instead ofa1anda2. Meanwhile, the localAstill points ata2. Thengh stack rebasecuts at the wrong commit and replays some ofA's commits along withb1andb2. They conflict with the squashed commit onmain, producing conflicts in filesBnever touched.This is especially a problem for squash merges, since Git can't tell that the squashed commit already contains
A's changes. I've been hitting it repeatedly, and it has forced me to rebase branches manually or edit the gh stack state to restore normal behavior.Fix
I wrote a fix for this in two commits, based on v0.2.0 (
maincommitd4ab7a):a20414bfix stale onto-boundary for merged branches16e4b73avoid the recorded base cache inresolveRebaseOldBaseChanges:
internal/github/github.go:HeadRefOidtoPullRequest. This is GitHub's record of the exact commit that was merged.cmd/utils.go: - (commit 1) When a PR is detected as merged, save itsHeadRefOid.HeadRefOidinstead of the possibly stale local SHA fromgit.Base, which can be just as stale.cmd/rebase_test.go:TestRebase_MergedBranch_PreferRemoteRef(local has SHAX, GitHub has the real merge pointY, and the tool picksY)TestRebase_MergedBranch_PreferForkPoint.I would open a PR for this but it's locked to contributors only. Full disclosure: I used Claude to identify and write the fix, but I manually reviewed and edited it afterwards.
Result
gh stack rebase's onto-boundary now comes from GitHub (can't go stale) instead of the local clone, eliminating confusing rebase conflicts due to a misconfigured rebase.