gh stack rebase: queued PR treated as merged, causing incorrect rebases for downstream branches

[skarim]

Reproduction

1. On a repo with stacked branches and PRs queued in the merge queue, run gh stack rebase.
2. Example observed output from a user report:

➜  token-scanning-service git:(aerendel/mixed-content-types3) gh stack rebase
✓ Fetched origin
✓ Trunk main fast-forwarded to aed1023
Stack detected: (main) <- aerendel/mixed-content-types1 <- aerendel/mixed-content-types2 <- aerendel/mixed-content-types3
Rebasing branches in order, starting from aerendel/mixed-content-types1 to aerendel/mixed-content-types3
✓ Skipping aerendel/mixed-content-types1 (PR #9333 queued)
✓ Rebased aerendel/mixed-content-types2 onto main (adjusted for merged PR)
✓ Rebased aerendel/mixed-content-types3 onto aerendel/mixed-content-types2 (adjusted for merged PR)
All branches in stack rebased locally with main
To push up your changes, run `gh stack push`

Actual behavior

• gh stack rebase treated a queued PR (PR #9333) as if it were merged when computing rebases for subsequent branches. The command skipped the first branch due to it being "queued", but then rebased the next branch "adjusted for merged PR", and treated the final branch as rebased onto the intermediate branch "adjusted for merged PR". This resulted in the second-layer branch being rebased as if the queued PR had already been merged.

Expected behavior

• Queued PRs in the merge queue (not yet merged into trunk) should NOT be treated as merged when computing rebases for downstream branches. gh stack rebase should preserve the stack order and rebase subsequent branches relative to the actual trunk and the true merge state (or otherwise clearly document and provide an option to treat queued PRs as merged).

Additional context

• Command used: gh stack rebase
• Observed in token-scanning-service example above (output pasted by user).

Suggested fix ideas

• Detect PRs that are only queued (not merged) and ensure they are not considered merged when adjusting base refs for downstream rebases.
• Add a flag or mode to opt-in to "treat queued PRs as merged" if there are valid workflows that expect that behavior.

Please let me know if you need logs or more reproduction details; the user who reported this is the original author of the pasted stack output.

View original Slack conversation