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
-
Checkout a branch in the middle of a stack:
-
Modify files and amend its commit:
git add .
git commit --amend
-
Push the stack:
-
Rebase the stack:
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
Description
When I amend a commit in a lower branch of a stack, then run
gh stack pushfollowed bygh stack rebase, the old version of the amended commit is replayed into the branches above it.Environment
gh stack version 0.0.8devStack structure
Steps to reproduce
Checkout a branch in the middle of a stack:
Modify files and amend its commit:
git add . git commit --amendPush the stack:
Rebase the stack:
Actual behavior
The previous version of the amended commit is replayed into an upstack branch.
The resulting history looked like this:
09c41aeshould not exist. It is a partial replay of the oldstage-runcommit rather than a legitimate commit belonging to that branch.Expected behavior
gh stack rebaseshould rebase each child using the previous parent commit as the old boundary, equivalent to: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:
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:
This goes with issue #193, I added more context, and reproductible steps