Re: bug?: ORIG_HEAD incorrect after reset during git-rebase -i
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jan 6, 2023, 14:29 UTC
- Message-ID
- <81218256-5354-4b0a-6f74-7e9605131968@dunelm.org.uk>
- In-Reply-To
- <ef389a14-8513-4650-21e4-89421a24df2d@gmail.com>
Hi Philippe & Erik
On 05/01/2023 00:11, Philippe Blain wrote:
Show 14 quoted lines
> Hi Phillip and Erik, > > Le 2021-12-16 à 11:44, Erik Cervin Edin a écrit : >> Hi Phillip, >> >> Yes, I know. >> It's just that I was under the impression ORIG_HEAD was to be reverted >> to .git/rebase-merge/orig-head at the finish of the rebase. >> Personally, it's the behavior I would expect. >> >> Thanks for the tips. > > I just hit the same bug (I think it qualifies as one). In fact git-rebase(1) explicitely mentions > that ORIG_HEAD is set to the branch tip before the rebase starts:
Strictly speaking that is what we do so we're documentation the implemented behavior. What's not clear from the documentation is that if the user run 'git reset' while rebasing then ORIG_HEAD will be overwritten. We could update ORIG_HEAD at the end of the rebase as you suggested but I wouldn't be surprised if some else complains that ORIG_HEAD no longer points to the commit that the reset while running rebase. I also wonder if users would expect 'git rebase --continue' to update ORIG_HEAD to point to the pre-rebase HEAD so it is consistent each time rebase stops. Basically I think the situation is confusing and I don't have a clear idea as to how to make it better. If someone submits a patch to try and clean things up I'll happily look at it but unless I'm hit by a bright idea as to how to fix it I probably wont work on it myself.
Best Wishes
Phillip
Show 89 quoted lines
> $ git grep -C2 ORIG_HEAD Documentation/git-rebase.txt
> Documentation/git-rebase.txt-36-The current branch is reset to `<upstream>` or `<newbase>` if the
> Documentation/git-rebase.txt-37-`--onto` option was supplied. This has the exact same effect as
> Documentation/git-rebase.txt:38:50:`git reset --hard <upstream>` (or `<newbase>`). `ORIG_HEAD` is set
> Documentation/git-rebase.txt-39-to point at the tip of the branch before the reset.
> Documentation/git-rebase.txt-40-
>
> Here is my runnable reproducer. It is slightly more complicated than Erik's, since
> I split the second commit in two, but this is not necessary to trigger the bug; just
> running 'git reset HEAD^' as Erik wrote is enough.
>
> ```bash
> #!/bin/bash
> rm -rf repro
> git init repro
> (
> cd repro
> # Create 3 commits
> cat << EOF >test
> hello
> every
> one
> EOF
> git add test
> git commit -m initial
> cat << EOF >test
> hello
>
> add new lines
>
> every
>
> and also here
>
> one
> EOF
> git commit -am second
> cat << EOF >test
> hello
>
> add new lines
>
> every
>
> and also here
>
> one
>
> still more changes
> EOF
> git commit -am third
> # Rebase to split the second commit
> GIT_SEQUENCE_EDITOR="sed -ie '1 s/^p /e /'" git rebase -i HEAD~2
> git reset HEAD^
> cat << EOF >test
> hello
>
> add new lines
>
> every
> one
> EOF
> git ci -am "second 1/2"
> cat <<EOF >test
> hello
>
> add new lines
>
> every
>
> and also here
>
> one
> EOF
> git ci -am "second 2/2"
> # Finish rebase and demonstrate bug
> git rebase --continue
> echo ---
> echo "@{1} is :"
> git log -1 @{1}
> echo "ORIG_HEAD is :"
> git log -1 ORIG_HEAD
>
> )
> ```
>
> Cheers,
>
> Philippe.