sync/rebase replays already-merged commits when the base PR was squash-merged

[AbhiPanseriya]

Summary

When the bottom PR of a stack is squash-merged into the trunk, gh stack sync and gh stack rebase try to replay the already-merged commits onto the remaining branches and hit conflicts. The "adjusted for merged PR" logic correctly drops the merged commits for the direct child of the merged PR, but branches further up the stack (grandchildren) still carry the original pre-squash commits, so the cascade replays them and conflicts against the squashed commit already on the trunk.

Environment

• gh 2.96.0
• gh stack v0.0.8

Setup

A stack off master: master <- A <- B <- C <- ... (7 PRs in our case). The bottom PR A is landed with Squash and merge, so master gets a brand-new squashed commit and A's original commits are not present in master.

Steps to reproduce

1. Land the bottom PR A with squash-merge.
2. Run gh stack sync (or gh stack rebase).

Actual

✓ Skipping A (PR #… merged)
✓ Rebased B onto master (adjusted for merged PR)
✗ Conflict detected rebasing C onto B
  All branches restored to their original state.

sync rolls everything back on the first conflict; gh stack rebase stops at it. The conflict markers show A's original commit being replayed (>>>>>>> <A's original commit>), colliding with the squashed version now on master. On a stack where a file is touched by several layers this produced ~12 conflicts on the affected branch and risked clobbering later layers' own edits to that file.

Root cause: B is rebased with the merged commits dropped, but C, D, ... still contain A's original commits in their history. The cascade replays them onto the rebuilt parent, because the merge-base of each grandchild with its rebuilt parent falls below A's commits.

Expected

sync/rebase should drop the squash-merged commits for every remaining branch in the stack, not just the direct child.

Workaround

Manual, per branch, bottom-up, using each branch's divergence point as the rebase upstream so only its own commits replay:

git rebase --onto master <merged-PR-tip> B
git rebase --onto B $(git merge-base <B-old-tip> C) C
git rebase --onto C $(git merge-base <C-old-tip> D) D
# ... then: gh stack push

gh stack view still recognizes the stack afterward (bases are tracked by metadata) and needsRebase clears. Verify with git merge-base --is-ancestor <A-original-commit> <branch> returning false for every remaining branch.

Suggestion

When a stack PR is detected as merged and its original SHAs are absent from the trunk (squash or rebase merge), apply the "adjust for merged PR" --onto drop across the whole upstack, not just the immediate child. A resumable --continue flow for sync (like rebase has) would also help, since sync currently rolls back entirely on the first conflict.

Thanks for the extension - the stacked workflow held up well across a 7-PR chain; this squash-merge cascade was the one sharp edge we hit while landing it.

[fridolin-koch]

We hit the same defect through a different trigger — no squash-merge involved: amending a mid-stack branch.

Setup (v0.0.8): main ← A ← B ← C ← D, all PRs open. Pushed review-feedback commits to A and B, then ran gh stack rebase. B rebased onto A fine, but the cascade then replayed B's original commit into C — .git/rebase-merge/git-rebase-todo literally shows pick <B's old commit> before C's own. Since the feedback commit on B touched files from B's earlier commit, the duplicate patch no longer applied cleanly → a conflict in every file the feedback commit touched.

So the cascade appears to run a plain git rebase <newParent> <branch> and rely on merge-base plus git's duplicate-patch dropping — even though .git/gh-stack records each branch's exact base. git rebase --onto <newParentHead> <recordedBase> <branch> would fix both this and the squash-merge case above; the metadata is already there.

Workaround: same shape as OP's — replay each layer's own commit range onto the rebuilt parent bottom-up, then repoint branches and the recorded heads/bases.