bug?: ORIG_HEAD incorrect after reset during git-rebase -i

Steps to reproduce:
1. git-rebase -i
2. edit XYZ
3. git-reset HEAD~
4. git-commit -C ORIG_HEAD -a
5. git-rebase --continue
6. git-show ORIG_HEAD

Expected behavior:
ORIG_HEAD should point at the previous HEAD of the rebased branch

Actual behavior:
ORIG_HEAD points to XYZ

My understanding from reading https://stackoverflow.com/a/64949884 is
that this is incorrect behavior.

Perhaps this is as intended but I would at least personally prefer
that ORIG_HEAD would point to the previous HEAD of the rebased branch.

Seen in:
git version 2.31.1.windows.1

Possibly related to
e100bea481 - rebase -i: stop overwriting ORIG_HEAD buffer

Hi Erik

On 16/12/2021 14:30, Erik Cervin Edin wrote:

Steps to reproduce:
1. git-rebase -i
2. edit XYZ
3. git-reset HEAD~

"git reset" will update ORIG_HEAD to the current HEAD before resetting 
so here ORIG_HEAD gets updated to point to XYZ

4. git-commit -C ORIG_HEAD -a
5. git-rebase --continue
6. git-show ORIG_HEAD

Expected behavior:
ORIG_HEAD should point at the previous HEAD of the rebased branch

Actual behavior:
ORIG_HEAD points to XYZ

My understanding from reading https://stackoverflow.com/a/64949884 is
that this is incorrect behavior.

Perhaps this is as intended but I would at least personally prefer
that ORIG_HEAD would point to the previous HEAD of the rebased branch.

You can use the reflog to get the previous HEAD of the rebased branch 
after rebasing. Immediately after the rebase branch-name@{1} will point 
to the pre-rebase HEAD.

Best Wishes

Phillip

Seen in:
git version 2.31.1.windows.1

Possibly related to
e100bea481 - rebase -i: stop overwriting ORIG_HEAD buffer

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.

Regards,
Erik

On Thu, Dec 16, 2021 at 5:27 PM Phillip Wood [off-list ref] wrote:

Hi Erik

On 16/12/2021 14:30, Erik Cervin Edin wrote:

quoted

Steps to reproduce:
1. git-rebase -i
2. edit XYZ
3. git-reset HEAD~

"git reset" will update ORIG_HEAD to the current HEAD before resetting
so here ORIG_HEAD gets updated to point to XYZ

quoted

4. git-commit -C ORIG_HEAD -a
5. git-rebase --continue
6. git-show ORIG_HEAD

Expected behavior:
ORIG_HEAD should point at the previous HEAD of the rebased branch

Actual behavior:
ORIG_HEAD points to XYZ

My understanding from reading https://stackoverflow.com/a/64949884 is
that this is incorrect behavior.

Perhaps this is as intended but I would at least personally prefer
that ORIG_HEAD would point to the previous HEAD of the rebased branch.

You can use the reflog to get the previous HEAD of the rebased branch
after rebasing. Immediately after the rebase branch-name@{1} will point
to the pre-rebase HEAD.

Best Wishes

Phillip

quoted

Seen in:
git version 2.31.1.windows.1

Possibly related to
e100bea481 - rebase -i: stop overwriting ORIG_HEAD buffer

-- 
Erik Cervin-Edin
Erik.CervinEd.in

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:

$ 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.

#!/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.

Hi Philippe & Erik

On 05/01/2023 00:11, Philippe Blain wrote:

Hi Phillip and Erik,

Le 2021-12-16 à 11:44, Erik Cervin Edin a écrit :

quoted

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

$ 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.

#!/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.

Hi Phillip,

Le 2023-01-06 à 09:29, Phillip Wood a écrit :

Hi Philippe & Erik

On 05/01/2023 00:11, Philippe Blain wrote:

quoted

Hi Phillip and Erik,

Le 2021-12-16 à 11:44, Erik Cervin Edin a écrit :

quoted

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. 

Yes, I agree. I think we could highlight it in the doc.

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.

Thanks for your thoughts. I think you make good points, it's true that 
some people might be relying on the current behaviour.

I'll try to send a few updates to the doc to make this hopefully clearer.

Cheers,
Philippe.

Le 2023-01-07 à 12:06, Philippe Blain a écrit :

Hi Phillip,

I'll try to send a few updates to the doc to make this hopefully clearer.

See https://lore.kernel.org/git/pull.1456.git.1673120359.gitgitgadget@gmail.com/T/#t