Closed (unmerged) PRs stay in a stack and block gh stack link from appending a new PR

[jonBerg24]

What happened

I had a two-PR stack, main → A (open) → B, where B was later closed without merging. Its branch still exists, but the PR is closed for good.

I then opened a new PR C that branches off A (a sibling of B, not a descendant), and tried to append it:

gh stack link A C

✗ Cannot update stack: this would remove #B from the stack
Current stack: #A, #B
Include all existing PRs in the command to update the stack

Because stacks are strictly linear and the closed B still occupies the only child slot under A, neither way forward is good:

1. gh stack link A B C keeps B, but rewrites C's base to B's branch, so C would be stacked on top of a closed, unmerged branch and its diff would change. Not what I want.
2. gh stack unstack <n> then gh stack link A C. This works (what I did), but it tears down and recreates the whole stack object, so the stack gets a new number and any stack-level state is lost. That feels heavy for "drop a PR that was closed anyway".

What I expected

A closed (not merged) PR is abandoned, so I'd expect it to stop participating in the stack. Either of these would have solved it:

• Auto-drop closed PRs from the stack, the way merged PRs are already handled specially, or
• Let link treat closed PRs as removable without a full unstack, so the additive-only guard only protects open and merged PRs. A flag would be fine too if the strictness is deliberate.

Right now the additive-only guard treats a closed PR as something worth protecting, which forces an unstack/relink cycle to make the stack reflect reality.

Minor related nit

To run unstack <n> I needed the stack number, but my current branch was not in the stack, and gh stack view --json only works from a branch that is. There didn't seem to be a CLI way to ask "what stack is PR #A in?", so I got the number from GraphQL:

{ repository(owner:"...", name:"..."){ pullRequest(number: A){ stack { number } } } }

Something like gh stack view --pr <number> --json would have saved the detour. Happy to split that into its own discussion if you'd prefer.

Versions

gh stack v0.0.8

[manyaagarwal]

+1 (had to remove existing stack and re stack PRs)