Repository navigation
Stack trunk is not migrated when the trunk branch's PR is squash-merged and the branch deleted #225
Description
Scenario
A stack whose trunk is itself a feature branch with its own PR to main (a common "stack on top of an in-review PR" setup):
main
└── feat/base → PR #1 (base: main) ← stack trunk, created with --base feat/base
└── feat/layer-2 → PR #2 (base: feat/base)
└── feat/layer-3 → PR #3 (base: feat/layer-2)
PR #1 is then squash-merged into main on GitHub and feat/base is deleted. GitHub automatically retargets PR #2's base to main.
Observed
The stack's local metadata keeps trunk: { branch: "feat/base", head: <old sha> } forever:
gh stack view --jsonstill reports the deleted branch as trunk.synccannot fast-forward the trunk (its remote ref no longer exists), and nothing offers to migrate the stack ontomain.- Because the trunk commits were squashed, the layers also need a
rebase --ontoto shed the now-duplicated trunk commits — the merged-PR recovery that works so nicely for stack members doesn't cover the trunk.
Expected
When the trunk's remote branch is gone and a merged PR from that branch into X exists, sync (or a dedicated command) should offer to migrate the stack trunk to X and cascade-rebase, mirroring the existing squash-merge recovery for in-stack branches. Even just a gh stack init --retrunk <branch> escape hatch would help — today init --adopt refuses branches that already have PRs, so there is no supported path.
Workaround that worked
git branch -f feat/base origin/main(keep the local trunk name, point it at main)gh stack rebase(cascades cleanly; git skips the squashed patches)- Hand-edit the
gh-stackJSON state file in.git/to settrunk: { branch: "main", head: <origin/main sha> }
After step 3, sync works normally again. Editing an internal state file obviously isn't a supported interface, hence this issue.
Version: gh-stack v0.0.8, gh 2.x, repo uses squash-merge as the default merge method.
Activity
favilo commentedon Aug 21, 2026
Hit this exact scenario today, with one twist that contradicts the
"GitHub automatically retargets PR #2's base" assumption: in our case the
platform closed the dependent PR instead of retargeting it (timeline:
merge at :28,
base_ref_deletedat :29,closedat :30 — see also #443).The merge was done with plain
gh pr merge --squash --delete-branch, notgh stack merge.Additional papercuts during recovery:
init --adoptrefuses branches already tracked in a stack, so afterhand-fixing the situation there was no supported way to re-trunk; I ended
up editing
.git/gh-stackdirectly (trunk →main, new head/base SHAs,new PR number).
(platform limitation), so the PR had to be recreated — the stack metadata
then pointed at a dead PR number.
A
gh stack syncthat detects "trunk PR merged + trunk branch deleted" andoffers re-trunk + cascade-rebase would have handled all of this.
favilo commentedon Aug 21, 2026
Follow-up: after manually re-trunking the stack onto
main, we tried tomerge the remaining layer with
gh stack merge— it turns out CLI mergingis not implemented at all:
So today there is no stack-aware merge path:
gh stack mergeis a stub thatredirects to the web UI, and falling back to
gh pr merge --delete-branchis exactly what produces the un-migrated trunk (this issue) and, in our
case, the platform closing the dependent PR instead of retargeting it
(#443). It would help if
mergeeither errored as unimplemented in--helpoutput or warned about the consequences of merging a trunk out from under
its stack.
favilo commentedon Aug 21, 2026
Version correction to my follow-up above: the "
gh stack mergeis notimplemented" experience was on gh-stack v0.0.1. After upgrading to
v0.1.0 we can see
gh stack mergeis now a real atomic stack merge — soplease disregard the stub-related part of that comment.
The trunk-migration issue itself (this issue's subject) was also observed on
v0.0.1 and we have not re-tested it on v0.1.0; if v0.1.0's merge/sync already
handles "trunk PR squash-merged + branch deleted", feel free to close and
we'll reopen if we hit it again on the current version.