Restack fails after squash-merge of bottom PR (stacked child keeps parent commits)

[jcmcneal]

Summary

Native stacked PR Rebase stack failed after the bottom PR was squash-merged into main. The child PR still carried the parent’s pre-squash commits, which no longer exist as the same SHAs on main, so restack could not reconcile them.

Context

• Org/repo: NerdWallet/insurance-flows
• Default merge method: squash and merge to main
• Stack: bottom PR #2086 → child PR #2088 (base was the bottom branch, later retargeted to main)

What happened

1. Bottom PR merged via squash → new commit on main; bottom branch deleted / no longer matches history.
2. Child PR still listed the bottom PR’s original commits plus its own unique commit.
3. GitHub UI Rebase stack failed (conflict / restack unsuccessful).
4. Local workaround worked cleanly:

git fetch origin
# <last-parent-sha> = tip of bottom branch before merge
git rebase --onto origin/main <last-parent-sha> feat/child
git push --force-with-lease

After that, the child PR correctly showed only its unique commit against main.

Ask

When the bottom of a stack is squash-merged, restack should:

1. Detect parent commits as already present on trunk (e.g. patch-id / equivalent change)
2. Drop those commits from children
3. Replay only child-unique commits onto main
4. Retarget PR bases to main

Squash-to-trunk is a very common default; without this, native stacks force a manual rebase --onto after every bottom merge.

Happy to share more detail if useful.

[mculp]

Same here.

github-merge-queue removed this pull request from the merge queue due to invalid changes in the merge commit

github-merge-queue removed this pull request from the merge queue because the pull requests in the stack were not ordered correctly in the queue

Then when I try to rebase the stack:

1 of 2 pull requests failed to rebase.

• Merge conflicts with #...

"Fully supported"

https://github.github.com/gh-stack/faq/#how-does-squash-merge-work