Description

When I amend a commit in a lower branch of a stack, then run gh stack push followed by gh stack rebase, the old version of the amended commit is replayed into the branches above it.

Environment

• gh stack version 0.0.8
• Linux
• Stack base: dev

Stack structure

dev
└─ A
   └─ B
      └─ C
         └─ ...

Steps to reproduce

1. Checkout a branch in the middle of a stack:

   gh stack checkout A

2. Modify files and amend its commit:

   git add .
   git commit --amend

3. Push the stack:

   gh stack push

4. Rebase the stack:

   gh stack rebase

Actual behavior

The previous version of the amended commit is replayed into an upstack branch.

The resulting history looked like this:

ae548b6 feat(A): Adding to branch A
└─ 86147e3 feat(B): Adding to branch B
   └─ 09c41ae feat(A): Adding to branch A
      └─ 9ded4fd chore(C): Adding to branch C

09c41ae should not exist. It is a partial replay of the old stage-run commit rather than a legitimate commit belonging to that branch.

Expected behavior

gh stack rebase should rebase each child using the previous parent commit as the old boundary, equivalent to:

git rebase --onto <new-parent> <old-parent> <child>

The amended commit should occur only once in the resulting history.

Workaround

Running the rebase before pushing avoids leaving the duplicated commit in the remote stack:

git commit --amend
gh stack rebase
gh stack push

However, the rebase still creates a conflict because it attempts to replay the old amended commit. After resolving that conflict, the stack can be pushed without the duplicated commit.

Otherwise, I have to repair each affected upstack branch manually with:

git rebase --onto <new-parent> <old-parent-sha> <child-branch>

This goes with issue #193, I added more context, and reproductible steps