On Wed, Jan 9, 2019 at 3:05 PM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Having said that, it is an unintended regression in the built-in rebase. > Markus, could you come up with a minimal test case, preferably in the form > of a patch to t/t3415-rebase-autosquash.sh? I don't think I'm familiar enough with the test code to be able to provide a good patch but the following code should illustrate the regression. git init testrepo cd testrepo echo 1 > file && git add file && git commit -m "initial" echo 1 >> file && git commit -am "commit 1" # rev_commit_1=$(git rev-parse HEAD) echo 1 >> file && git commit -am "fixup! $(git rev-parse --short HEAD)" echo 1 >> file && git commit -am "commit 3" rev_orig_head=$(git rev-parse HEAD) GIT_EDITOR=: git rebase --autosquash -i HEAD~3 test $(git rev-parse ORIG_HEAD) = $rev_orig_head In older versions of git this test succeeded, i.e. ORIG_HEAD pointed to the previous original head, $rev_orig_head. In git version 2.20.1 ORIG_HEAD now points to the commit that got fixuped instead, $rev_commit_1. In previous versions ORIG_HEAD only pointed somewhere else if "git reset" was invoked manually during the rebase operation. I'm not sure if this is desirable, maybe ORIG_HEAD should always point to the previous head after rebase completes, no matter what operations were run in between. What do you think? Markus
