Merging the bottom of a stack should retire that PR and settle the stack on its base

[altwohill]

Expected: merging the bottom PR of a stack removes it from the stack and settles the stack onto that PR's base, leaving a stack one shorter.

Observed: the merged PR stays in the stack permanently, and the PR above it keeps the merged branch as its base.

Two separate failures on one 3-PR stack this week both trace back to this.

1. The dependent PR is not retargeted when the bottom merges

Stack was A -> B -> C (each PR based on the branch below, A based on develop).

When A merged, B's base stayed on A's branch. A non-stacked PR whose base branch is merged gets auto-retargeted to the merged branch's base; that does not appear to happen for stacked PRs. Because A had been rebased before merging, B's merge base was now far behind and its diff swallowed everything develop had gained in the meantime — it showed as conflicting with roughly twice the real file count.

Retargeting B to develop was refused by both REST and GraphQL:

Cannot change the base branch because the pull request is part of a stack.

So the obvious repair was unavailable. Deleting A's merged branch — normal post-merge cleanup, and the usual trigger for retargeting dependents — instead closed B outright, and it could not be reopened because its base branch no longer existed. An approved PR had to be recreated from scratch, losing its review.

2. A merged PR can never leave its stack

$ gh stack unstack 1319
✗ Unstacking not allowed: Pull request #1317 cannot be removed from this stack

#1317 had merged over a day earlier. The stack can therefore never be dissolved.

Two notes on that command: it does silently remove the still-open members before hitting the merged one, so the outcome was actually what I wanted — but the error message suggests nothing happened at all, and the stack is left open: false containing only the merged PR. (The misleading-error part is #372.)

Why this seems like one root cause

If a PR were retired from its stack on merge, neither of the above arises: the stack settles onto the merged PR's base, dependents retarget the way non-stacked PRs already do, and no stack is left holding an unremovable member. It also looks like it would subsume a good part of the "merged/closed PRs stuck in a stack" reports — #230, #382, #428, and the trunk-migration half of #225.

Worth saying that the failure mode is quiet: at no point did anything warn that merging the bottom of a stack would leave the PR above it stranded, or that deleting the merged branch would close it.