gh pr merge --squash --delete-branch: dependent PR closed instead of auto-retargeted to merged PR's base

[favilo]

What happened

A stacked-PR setup: PR #8 (feat/fix → base feat/base), where feat/base
was the head of open PR #7 (feat/base → main). The stack was assembled
with gh stack init --adopt — PR #7 predated the stack and was adopted as
the trunk when the descendant PR was created via gh stack submit. Both were
otherwise ordinary PRs with an ordinary base relationship.

I then ran: gh pr merge 7 --squash --delete-branch

Per the docs, deleting a merged PR's head branch should retarget open PRs
based on it to the merged PR's base branch. Instead, PR #8 was closed.

Timeline evidence (gh api repos/OWNER/REPO/issues/8/timeline):

• 19:56:28Z — PR Start on context package #7 merged (squash)
• 19:56:29Z — base_ref_deleted event on PR Pull in the GraphQL API functionality #8
• 19:56:30Z — closed event on PR Pull in the GraphQL API functionality #8 (no retarget attempted)

Recovery was a dead end

• gh pr edit 8 --base main on the closed PR: "Cannot change the base branch
  of a closed pull request."
• gh pr reopen 8: refused while the base branch was deleted (expected), but
  also refused after restoring the base branch, because the head branch
  had been rebased/pushed while the PR was closed. Catch-22: the PR had to be
  abandoned and recreated as a new PR, losing its identity.

Questions

1. Is auto-retarget on branch deletion only wired to the web UI's post-merge
   "delete branch" flow, and not to a raw ref deletion via the REST API
   (which is what --delete-branch performs)?
2. If so, should gh pr merge --delete-branch warn when open PRs are based
   on the branch being deleted?

(If this is platform-side rather than CLI-side, happy to have it routed.)

[cli-triage]

Thanks for the detailed report and timeline evidence. I'm suggesting the bug label, since this describes a clear discrepancy between documented behavior (auto-retargeting open PRs after a merged PR's head branch is deleted) and what actually happened (the dependent PR was closed instead). I didn't find an existing duplicate issue after searching for related terms (retarget, base branch deleted, delete-branch). Since this may involve GitHub's server-side auto-retarget logic rather than gh CLI code itself, a maintainer may want to confirm whether --delete-branch's branch deletion API call differs from the web UI's flow, and possibly add a warning as suggested in the issue.

Generated by Issue Triage (skills-driven) for #14223 · auto · 25.5 AIC · ⌖ 1.47 AIC · ⊞ 9.7K · ◷

[favilo]

Additional context: after recovering the stack, we tried the ostensibly
stack-aware alternative — gh stack merge from the github/gh-stack
extension — but CLI merging is not implemented there either ("Merging
stacked PRs from the CLI is not yet supported", redirects to the web UI).

So as of gh 2.97.0 + gh-stack 0.0.1, gh pr merge --delete-branch is the
only CLI merge path, and it exhibits the close-instead-of-retarget
behavior reported above. That raises the stakes on either fixing the
retarget trigger for API-driven branch deletion or adding the proposed
warning when open PRs are based on the branch being deleted.

[favilo]

Version correction: the behavior above was observed with gh 2.97.0 (and
gh-stack v0.0.1). We have since upgraded to gh 2.98.0 but have not re-run the
scenario, so we can't say whether anything changed — and since the retarget
logic is likely platform-side, a CLI bump may not affect it either way.

One correction to my previous comment: gh-stack v0.1.0 (released
2026-07-29) does implement gh stack merge as an atomic all-or-nothing
stack merge — the "not yet supported" stub we hit was v0.0.1. So there is
now a stack-aware CLI merge path; we just hadn't upgraded the extension.

[williammartin]

Hey @favilo, thanks for reporting.

The TL;DR is that this looks like a platform bug based on how stacked PRs interact with the endpoints that gh calls to merge PRs. They are tracking this work, though I have no ETA for when it might get done.

Regarding your questions:

1. I don't think this has anything to do with --delete-branch, the issue seems to be related to retargeting when the PR is part of a stack.
2. Potentially we could do a client side warning but I'm a bit hesitant because once the platform team fix this, that warning is going to exist in older versions people might still be running.

Gonna mark this as a bug blocked on platform for now and see where we get to.

[williammartin]

I created this acceptance test which I think captures your report. Maybe if you have a moment you could look at the relevant git branch / PR configurations and let me know if its accurately matches your scenario. Roughly it is:

1. Create feat-base from main, then push it and open PR #1 targeting main.
2. Create feat-fix from feat-base, add a commit, and push it.
3. Ran gh stack init --base feat-base feat-fix.
4. Run gh stack submit --auto, create PR #2 targeting feat-base.
5. Run gh pr merge <PR #1> --squash --delete-branch from main.
6. PR #1 is merged, but PR #2 is closed with its base still set to the deleted feat-base branch.

# Check whether cli/cli#14223 still reproduces with the latest gh-stack release.
#
# As in the original report, the existing base PR is the trunk of a local
# gh-stack and only the descendant PR is a stack member. With only one stack PR,
# gh-stack does not create a native server-side Stack object.

# Use gh as a credential helper
exec gh auth setup-git

# Install the latest gh-stack release
exec gh extension install github/gh-stack
defer gh extension remove stack

# Create and clone an isolated repository
exec gh repo create $ORG/$SCRIPT_NAME-$RANDOM_STRING --add-readme --private
defer gh repo delete --yes $ORG/$SCRIPT_NAME-$RANDOM_STRING
exec gh repo clone $ORG/$SCRIPT_NAME-$RANDOM_STRING
cd $SCRIPT_NAME-$RANDOM_STRING

# Create the pre-existing base PR: feat-base -> main
exec git checkout -b feat-base
mv ../base.txt base.txt
exec git add .
exec git commit -m 'Add base.txt'
exec git push -u origin feat-base
exec gh pr create --base main --head feat-base --title 'Base PR' --body 'Base body'
stdout2env BASE_PR_URL

# Create a descendant branch from the base PR branch
exec git checkout -b feat-fix
mv ../fix.txt fix.txt
exec git add .
exec git commit -m 'Add fix.txt'
exec git push -u origin feat-fix

# Current gh-stack adopts existing named branches automatically. Use the
# pre-existing PR branch as the trunk and submit only the descendant.
exec gh stack init --base feat-base feat-fix
exec gh stack submit --auto
exec gh pr view feat-fix --json url --jq .url
stdout2env DEPENDENT_PR_URL

# Preserve the original base branch tip so it can be restored during recovery
exec git rev-parse feat-base
stdout2env BASE_BRANCH_SHA

# Merge and delete the stack trunk exactly as reported
exec git checkout main
exec gh pr merge $BASE_PR_URL --squash --delete-branch

# Confirm the base PR merged, then allow branch-deletion side effects to settle
exec gh pr view $BASE_PR_URL --json state
stdout2env BASE_PR_JSON
jq-assert BASE_PR_JSON '.state' '^MERGED$'
sleep 5

# BUG: if the issue still reproduces, the dependent PR closes instead of
# remaining open and retargeting to main.
exec gh pr view $DEPENDENT_PR_URL --json state,baseRefName
stdout2env DEPENDENT_PR_JSON
jq-assert DEPENDENT_PR_JSON '.state' '^CLOSED$'
jq-assert DEPENDENT_PR_JSON '.baseRefName' '^feat-base$'

# Changing the base is refused while the dependent PR is closed
! exec gh pr edit $DEPENDENT_PR_URL --base main
stderr 'Cannot change the base branch of a closed pull request'

# Reopening is refused while the base branch remains deleted
! exec gh pr reopen $DEPENDENT_PR_URL
exec gh pr view $DEPENDENT_PR_URL --json state
stdout2env DEPENDENT_PR_JSON
jq-assert DEPENDENT_PR_JSON '.state' '^CLOSED$'

# Rebase and force-push the dependent head while the PR is closed
exec git fetch origin main
exec git rebase --onto origin/main $BASE_BRANCH_SHA feat-fix
exec git push --force-with-lease origin feat-fix

# Restore the deleted base branch at its original tip
exec git push origin $BASE_BRANCH_SHA:refs/heads/feat-base
exec gh api repos/$ORG/$SCRIPT_NAME-$RANDOM_STRING/git/ref/heads/feat-base --jq .ref
stdout 'refs/heads/feat-base'

# Reopening is still refused after restoring the base because the dependent
# head branch was rebased and pushed while the PR was closed
! exec gh pr reopen $DEPENDENT_PR_URL
exec gh pr view $DEPENDENT_PR_URL --json state
stdout2env DEPENDENT_PR_JSON
jq-assert DEPENDENT_PR_JSON '.state' '^CLOSED$'

-- base.txt --
Base branch contents
-- fix.txt --
Dependent branch contents

What I didn't realise from your original report was that the --adopt probably didn't create a server side stack. When you try to use pr merge on a server side stack, you end up getting this error:

> exec gh pr merge $BASE_PR_URL --squash --delete-branch
[stderr]
GraphQL: This pull request is part of a stack and must be merged using the asynchronous merge REST API. For more information, see https://docs.github.com/rest/pulls/pulls#merge-a-pull-request-asynchronously (mergePullRequest)

[favilo]

That definitely looks correct on the sequence of events.

And the --adopt issue does make sense. Do you know if there is a way to convert a PR to a stack with the current tools? Because I'm definitely going to end up doing something like this, as I realize I need to add something on top of an already pushed PR.

As it is, I just manually create the stacks and retrofit links between the descriptions. And that is my fallback