threads / discuss / 54487

ORIG_HEAD after rebase is confusing

Subject: ORIG_HEAD after rebase is confusing

## tl;dr

5 messages between Oct 22, 2020 and Oct 26, 2020.

replies: 4people: 2as markdown or json

herr.kaste· Oct 22, 2020, 20:31 UTC · lore

Reading the git rebase manual and some answer on stackoverflow I assumed `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before* I started rebasing. But it doesn't seem so.

For example, I have this:

  $ git log --graph --all --oneline
  * 9830f9f (master) X
  | * fb7b6a6 (HEAD -> feature) D
  | * 46b7a7a C
  | * da5e4c7 B
  | * 5c135da A
  |/
  * 6848823 Init

  $ git rebase master
  Successfully rebased and updated refs/heads/feature.

  $ git rev-parse ORIG_HEAD
  da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7

  $ git reflog
  a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to
refs/heads/feature
  a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D
  2f458e8 HEAD@{2}: rebase (pick): C
  0aa2160 HEAD@{3}: rebase (pick): B
  b957fc7 HEAD@{4}: rebase (pick): A
  9830f9f (master) HEAD@{5}: rebase (start): checkout master
  fb7b6a6 HEAD@{6}: checkout: moving from master to feature
  9830f9f (master) HEAD@{7}: commit: X
  6848823 HEAD@{8}: checkout: moving from feature to master
  fb7b6a6 HEAD@{9}: commit: D
  46b7a7a HEAD@{10}: commit: C
  da5e4c7 HEAD@{11}: commit: B
  5c135da HEAD@{12}: commit: A
  6848823 HEAD@{13}: checkout: moving from master to feature
  6848823 HEAD@{14}: commit (initial): Init

So `ORIG_HEAD` here points to the original B commit. (I expected the D.) Honestly, this doesn't make much sense to me in that I don't know *why* it even chooses B which is a middle commit in the chain. (And from reading the source `sequencer.c` I can't deduce it either.)

  $ git --version
  git version 2.29.0.windows.1

What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw. And for example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge conflict.

Regards, Caspar Duregger

Phillip Wood· Oct 26, 2020, 10:43 UTC · re: herr.kaste · lore

Re: ORIG_HEAD after rebase is confusing

Hi Caspar

On 22/10/2020 21:31, herr.kaste wrote:

Show 41 quoted lines

> Reading the git rebase manual and some answer on stackoverflow I assumed
> `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*
> I started rebasing.  But it doesn't seem so.
> 
> For example, I have this:
> 
> 
>    $ git log --graph --all --oneline
>    * 9830f9f (master) X
>    | * fb7b6a6 (HEAD -> feature) D
>    | * 46b7a7a C
>    | * da5e4c7 B
>    | * 5c135da A
>    |/
>    * 6848823 Init
> 
>    $ git rebase master
>    Successfully rebased and updated refs/heads/feature.
> 
>    $ git rev-parse ORIG_HEAD
>    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7
> 
>    $ git reflog
>    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to
> refs/heads/feature
>    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D
>    2f458e8 HEAD@{2}: rebase (pick): C
>    0aa2160 HEAD@{3}: rebase (pick): B
>    b957fc7 HEAD@{4}: rebase (pick): A
>    9830f9f (master) HEAD@{5}: rebase (start): checkout master
>    fb7b6a6 HEAD@{6}: checkout: moving from master to feature
>    9830f9f (master) HEAD@{7}: commit: X
>    6848823 HEAD@{8}: checkout: moving from feature to master
>    fb7b6a6 HEAD@{9}: commit: D
>    46b7a7a HEAD@{10}: commit: C
>    da5e4c7 HEAD@{11}: commit: B
>    5c135da HEAD@{12}: commit: A
>    6848823 HEAD@{13}: checkout: moving from master to feature
>    6848823 HEAD@{14}: commit (initial): Init
> 
> So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)

It should be D, unless you ran `git reset` or `git rebase --skip` while you were rebasing as they also update ORIG_HEAD

Show 10 quoted lines

> Honestly, this doesn't make much sense to me in that I don't know *why* it
> even chooses B which is a middle commit in the chain.  (And from reading the
> source `sequencer.c` I can't deduce it either.)
> 
>    $ git --version
>    git version 2.29.0.windows.1
> 
> What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for
> example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge
> conflict.

After you rebase you can user feature@{1} to get the head of feature before rebasing (until you make another commit on feature)

Best Wishes

Phillip

> Regards,
> Caspar Duregger
>

herr.kaste· Oct 26, 2020, 11:29 UTC · re: Phillip Wood · lore

Re: ORIG_HEAD after rebase is confusing

Hi Philipp,

for whatever reason that doesn't work. I know the `feature@{1}` trick but hoped just `ORIG_HEAD` would work. Or maybe it used to work, it's not an everyday command.

Following is my test case:

    $ git init; git commit --allow-empty -m "Init"
    [master (root-commit) 5db5264] Init

    c-flo@KLOG MINGW64 /d/rebtest (master)
    $ git co -b feature
    Switched to a new branch 'feature'

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git commit --allow-empty -m "A"
    [feature 5c7dfb4] A

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git commit --allow-empty -m "B"
    [feature a61bd4c] B

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git commit --allow-empty -m "C"
    [feature 26e6417] C

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git commit --allow-empty -m "D"
    [feature 735e4fb] D

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git co master
    Switched to branch 'master'

    c-flo@KLOG MINGW64 /d/rebtest (master)
    $ git commit --allow-empty -m "X"
    [master 3eb6a3f] X

    c-flo@KLOG MINGW64 /d/rebtest (master)
    $ git co feature
    Switched to branch 'feature'

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git rev-parse ORIG_HEAD
    fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path
not in the working tree.
    Use '--' to separate paths from revisions, like this:
    'git <command> [<revision>...] -- [<file>...]'
    ORIG_HEAD

Intentional, up to this point I did nothing that sets `ORIG_HEAD`.

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git rebase master
    Successfully rebased and updated refs/heads/feature.

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git rev-parse ORIG_HEAD
    a61bd4c550396ac086879aea829375d839a1667b

    c-flo@KLOG MINGW64 /d/rebtest (feature)
    $ git rev-parse feature@{1}
    735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d

So here again, `ORIG_HEAD` points to the original B. And `feature@{1}` correctly points to the original D. I obviously did no `rebase --skip` here. Is there an internal `git --reset` somewhere here I'm missing?

Anyhow, you said it should work unless there is an `git --reset` or `--skip` **while** rebasing. So I guess the relatively declarative usage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone for example if I use `-i --rebase-merges`.

That is, I actually wonder if you set `ORIG_HEAD` more at the start of the rebasing work, or basically in the cleanup function of the rebase, e.g. when you delete the `orig-head` file. It looks like the former, and I assumed the latter.

Regards, Caspar Duregger

Am Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood <phillip.wood123@gmail.com>:

Show 71 quoted lines

>
> Hi Caspar
>
> On 22/10/2020 21:31, herr.kaste wrote:
> > Reading the git rebase manual and some answer on stackoverflow I assumed
> > `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*
> > I started rebasing.  But it doesn't seem so.
> >
> > For example, I have this:
> >
> >
> >    $ git log --graph --all --oneline
> >    * 9830f9f (master) X
> >    | * fb7b6a6 (HEAD -> feature) D
> >    | * 46b7a7a C
> >    | * da5e4c7 B
> >    | * 5c135da A
> >    |/
> >    * 6848823 Init
> >
> >    $ git rebase master
> >    Successfully rebased and updated refs/heads/feature.
> >
> >    $ git rev-parse ORIG_HEAD
> >    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7
> >
> >    $ git reflog
> >    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to
> > refs/heads/feature
> >    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D
> >    2f458e8 HEAD@{2}: rebase (pick): C
> >    0aa2160 HEAD@{3}: rebase (pick): B
> >    b957fc7 HEAD@{4}: rebase (pick): A
> >    9830f9f (master) HEAD@{5}: rebase (start): checkout master
> >    fb7b6a6 HEAD@{6}: checkout: moving from master to feature
> >    9830f9f (master) HEAD@{7}: commit: X
> >    6848823 HEAD@{8}: checkout: moving from feature to master
> >    fb7b6a6 HEAD@{9}: commit: D
> >    46b7a7a HEAD@{10}: commit: C
> >    da5e4c7 HEAD@{11}: commit: B
> >    5c135da HEAD@{12}: commit: A
> >    6848823 HEAD@{13}: checkout: moving from master to feature
> >    6848823 HEAD@{14}: commit (initial): Init
> >
> > So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)
>
> It should be D, unless you ran `git reset` or `git rebase --skip` while
> you were rebasing as they also update ORIG_HEAD
>
> > Honestly, this doesn't make much sense to me in that I don't know *why* it
> > even chooses B which is a middle commit in the chain.  (And from reading the
> > source `sequencer.c` I can't deduce it either.)
> >
> >    $ git --version
> >    git version 2.29.0.windows.1
> >
> > What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for
> > example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge
> > conflict.
>
> After you rebase you can user feature@{1} to get the head of feature
> before rebasing (until you make another commit on feature)
>
> Best Wishes
>
> Phillip
>
> > Regards,
> > Caspar Duregger
> >
>

herr.kaste· Oct 26, 2020, 11:45 UTC · re: herr.kaste · lore

Re: ORIG_HEAD after rebase is confusing

Sorry, Phillip not Philipp.

There is a bug here I think. The following works as expected, t.i. `ORIG_HEAD == feature@{1}`.

    git init
    git commit --allow-empty -m "Init"
    git co -b feature
    git commit --allow-empty -m "A"
    git commit --allow-empty -m "B"
    git commit --allow-empty -m "C"
    git commit --allow-empty -m "D"
    git commit --allow-empty -m "E"
    git commit --allow-empty -m "F"
    git co master
    git commit --allow-empty -m "X"
    git co feature
    git rebase master
    git rev-parse ORIG_HEAD
    git rev-parse feature@{1}

But if you omit commit `F` or both `F` and `E` it doesn't.

Regards, Caspar Duregger

Am Mo., 26. Okt. 2020 um 12:29 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:

Show 157 quoted lines

>
> Hi Philipp,
>
> for whatever reason that doesn't work.  I know the `feature@{1}` trick
> but hoped just `ORIG_HEAD` would work.  Or maybe it used to work, it's not
> an everyday command.
>
> Following is my test case:
>
>     $ git init; git commit --allow-empty -m "Init"
>     [master (root-commit) 5db5264] Init
>
>     c-flo@KLOG MINGW64 /d/rebtest (master)
>     $ git co -b feature
>     Switched to a new branch 'feature'
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git commit --allow-empty -m "A"
>     [feature 5c7dfb4] A
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git commit --allow-empty -m "B"
>     [feature a61bd4c] B
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git commit --allow-empty -m "C"
>     [feature 26e6417] C
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git commit --allow-empty -m "D"
>     [feature 735e4fb] D
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git co master
>     Switched to branch 'master'
>
>     c-flo@KLOG MINGW64 /d/rebtest (master)
>     $ git commit --allow-empty -m "X"
>     [master 3eb6a3f] X
>
>     c-flo@KLOG MINGW64 /d/rebtest (master)
>     $ git co feature
>     Switched to branch 'feature'
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git rev-parse ORIG_HEAD
>     fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path
> not in the working tree.
>     Use '--' to separate paths from revisions, like this:
>     'git <command> [<revision>...] -- [<file>...]'
>     ORIG_HEAD
>
> Intentional, up to this point I did nothing that sets `ORIG_HEAD`.
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git rebase master
>     Successfully rebased and updated refs/heads/feature.
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git rev-parse ORIG_HEAD
>     a61bd4c550396ac086879aea829375d839a1667b
>
>     c-flo@KLOG MINGW64 /d/rebtest (feature)
>     $ git rev-parse feature@{1}
>     735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d
>
> So here again, `ORIG_HEAD` points to the original B.  And `feature@{1}`
> correctly points to the original D.  I obviously did no `rebase --skip`
> here.  Is there an internal `git --reset` somewhere here I'm missing?
>
> Anyhow, you said it should work unless there is an `git --reset` or
> `--skip` **while** rebasing.  So I guess the relatively declarative
> usage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone
> for example if I use `-i --rebase-merges`.
>
> That is, I actually wonder if you set `ORIG_HEAD` more at the start of the
> rebasing work, or basically in the cleanup function of the rebase, e.g. when you
> delete the `orig-head` file.  It looks like the former, and I assumed
> the latter.
>
>
> Regards,
> Caspar Duregger
>
> Am Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood
> <phillip.wood123@gmail.com>:
> >
> > Hi Caspar
> >
> > On 22/10/2020 21:31, herr.kaste wrote:
> > > Reading the git rebase manual and some answer on stackoverflow I assumed
> > > `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*
> > > I started rebasing.  But it doesn't seem so.
> > >
> > > For example, I have this:
> > >
> > >
> > >    $ git log --graph --all --oneline
> > >    * 9830f9f (master) X
> > >    | * fb7b6a6 (HEAD -> feature) D
> > >    | * 46b7a7a C
> > >    | * da5e4c7 B
> > >    | * 5c135da A
> > >    |/
> > >    * 6848823 Init
> > >
> > >    $ git rebase master
> > >    Successfully rebased and updated refs/heads/feature.
> > >
> > >    $ git rev-parse ORIG_HEAD
> > >    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7
> > >
> > >    $ git reflog
> > >    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to
> > > refs/heads/feature
> > >    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D
> > >    2f458e8 HEAD@{2}: rebase (pick): C
> > >    0aa2160 HEAD@{3}: rebase (pick): B
> > >    b957fc7 HEAD@{4}: rebase (pick): A
> > >    9830f9f (master) HEAD@{5}: rebase (start): checkout master
> > >    fb7b6a6 HEAD@{6}: checkout: moving from master to feature
> > >    9830f9f (master) HEAD@{7}: commit: X
> > >    6848823 HEAD@{8}: checkout: moving from feature to master
> > >    fb7b6a6 HEAD@{9}: commit: D
> > >    46b7a7a HEAD@{10}: commit: C
> > >    da5e4c7 HEAD@{11}: commit: B
> > >    5c135da HEAD@{12}: commit: A
> > >    6848823 HEAD@{13}: checkout: moving from master to feature
> > >    6848823 HEAD@{14}: commit (initial): Init
> > >
> > > So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)
> >
> > It should be D, unless you ran `git reset` or `git rebase --skip` while
> > you were rebasing as they also update ORIG_HEAD
> >
> > > Honestly, this doesn't make much sense to me in that I don't know *why* it
> > > even chooses B which is a middle commit in the chain.  (And from reading the
> > > source `sequencer.c` I can't deduce it either.)
> > >
> > >    $ git --version
> > >    git version 2.29.0.windows.1
> > >
> > > What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for
> > > example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge
> > > conflict.
> >
> > After you rebase you can user feature@{1} to get the head of feature
> > before rebasing (until you make another commit on feature)
> >
> > Best Wishes
> >
> > Phillip
> >
> > > Regards,
> > > Caspar Duregger
> > >
> >

Phillip Wood· Oct 26, 2020, 16:42 UTC · re: herr.kaste · lore

Re: ORIG_HEAD after rebase is confusing

Hi Capsar

On 26/10/2020 11:45, herr.kaste wrote:

> Sorry, Phillip not Philipp.

> There is a bug here I think.  The following works as expected, t.i.

Yes there is a bug - we are overwriting a statically allocated buffer holding the abbreviated OID, thanks for the reproduction recipe. I've got a fix locally, I'll clean it up and post it in the next couple of days.

Best Wishes

Phillip

Show 182 quoted lines

> `ORIG_HEAD == feature@{1}`.
> 
>      git init
>      git commit --allow-empty -m "Init"
>      git co -b feature
>      git commit --allow-empty -m "A"
>      git commit --allow-empty -m "B"
>      git commit --allow-empty -m "C"
>      git commit --allow-empty -m "D"
>      git commit --allow-empty -m "E"
>      git commit --allow-empty -m "F"
>      git co master
>      git commit --allow-empty -m "X"
>      git co feature
>      git rebase master
>      git rev-parse ORIG_HEAD
>      git rev-parse feature@{1}
> 
> But if you omit commit `F` or both `F` and `E` it doesn't.
> 
> Regards,
> Caspar Duregger
> 
> 
> Am Mo., 26. Okt. 2020 um 12:29 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:
>>
>> Hi Philipp,
>>
>> for whatever reason that doesn't work.  I know the `feature@{1}` trick
>> but hoped just `ORIG_HEAD` would work.  Or maybe it used to work, it's not
>> an everyday command.
>>
>> Following is my test case:
>>
>>      $ git init; git commit --allow-empty -m "Init"
>>      [master (root-commit) 5db5264] Init
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (master)
>>      $ git co -b feature
>>      Switched to a new branch 'feature'
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git commit --allow-empty -m "A"
>>      [feature 5c7dfb4] A
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git commit --allow-empty -m "B"
>>      [feature a61bd4c] B
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git commit --allow-empty -m "C"
>>      [feature 26e6417] C
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git commit --allow-empty -m "D"
>>      [feature 735e4fb] D
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git co master
>>      Switched to branch 'master'
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (master)
>>      $ git commit --allow-empty -m "X"
>>      [master 3eb6a3f] X
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (master)
>>      $ git co feature
>>      Switched to branch 'feature'
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git rev-parse ORIG_HEAD
>>      fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path
>> not in the working tree.
>>      Use '--' to separate paths from revisions, like this:
>>      'git <command> [<revision>...] -- [<file>...]'
>>      ORIG_HEAD
>>
>> Intentional, up to this point I did nothing that sets `ORIG_HEAD`.
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git rebase master
>>      Successfully rebased and updated refs/heads/feature.
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git rev-parse ORIG_HEAD
>>      a61bd4c550396ac086879aea829375d839a1667b
>>
>>      c-flo@KLOG MINGW64 /d/rebtest (feature)
>>      $ git rev-parse feature@{1}
>>      735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d
>>
>> So here again, `ORIG_HEAD` points to the original B.  And `feature@{1}`
>> correctly points to the original D.  I obviously did no `rebase --skip`
>> here.  Is there an internal `git --reset` somewhere here I'm missing?
>>
>> Anyhow, you said it should work unless there is an `git --reset` or
>> `--skip` **while** rebasing.  So I guess the relatively declarative
>> usage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone
>> for example if I use `-i --rebase-merges`.
>>
>> That is, I actually wonder if you set `ORIG_HEAD` more at the start of the
>> rebasing work, or basically in the cleanup function of the rebase, e.g. when you
>> delete the `orig-head` file.  It looks like the former, and I assumed
>> the latter.
>>
>>
>> Regards,
>> Caspar Duregger
>>
>> Am Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood
>> <phillip.wood123@gmail.com>:
>>>
>>> Hi Caspar
>>>
>>> On 22/10/2020 21:31, herr.kaste wrote:
>>>> Reading the git rebase manual and some answer on stackoverflow I assumed
>>>> `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*
>>>> I started rebasing.  But it doesn't seem so.
>>>>
>>>> For example, I have this:
>>>>
>>>>
>>>>     $ git log --graph --all --oneline
>>>>     * 9830f9f (master) X
>>>>     | * fb7b6a6 (HEAD -> feature) D
>>>>     | * 46b7a7a C
>>>>     | * da5e4c7 B
>>>>     | * 5c135da A
>>>>     |/
>>>>     * 6848823 Init
>>>>
>>>>     $ git rebase master
>>>>     Successfully rebased and updated refs/heads/feature.
>>>>
>>>>     $ git rev-parse ORIG_HEAD
>>>>     da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7
>>>>
>>>>     $ git reflog
>>>>     a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to
>>>> refs/heads/feature
>>>>     a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D
>>>>     2f458e8 HEAD@{2}: rebase (pick): C
>>>>     0aa2160 HEAD@{3}: rebase (pick): B
>>>>     b957fc7 HEAD@{4}: rebase (pick): A
>>>>     9830f9f (master) HEAD@{5}: rebase (start): checkout master
>>>>     fb7b6a6 HEAD@{6}: checkout: moving from master to feature
>>>>     9830f9f (master) HEAD@{7}: commit: X
>>>>     6848823 HEAD@{8}: checkout: moving from feature to master
>>>>     fb7b6a6 HEAD@{9}: commit: D
>>>>     46b7a7a HEAD@{10}: commit: C
>>>>     da5e4c7 HEAD@{11}: commit: B
>>>>     5c135da HEAD@{12}: commit: A
>>>>     6848823 HEAD@{13}: checkout: moving from master to feature
>>>>     6848823 HEAD@{14}: commit (initial): Init
>>>>
>>>> So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)
>>>
>>> It should be D, unless you ran `git reset` or `git rebase --skip` while
>>> you were rebasing as they also update ORIG_HEAD
>>>
>>>> Honestly, this doesn't make much sense to me in that I don't know *why* it
>>>> even chooses B which is a middle commit in the chain.  (And from reading the
>>>> source `sequencer.c` I can't deduce it either.)
>>>>
>>>>     $ git --version
>>>>     git version 2.29.0.windows.1
>>>>
>>>> What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for
>>>> example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge
>>>> conflict.
>>>
>>> After you rebase you can user feature@{1} to get the head of feature
>>> before rebasing (until you make another commit on feature)
>>>
>>> Best Wishes
>>>
>>> Phillip
>>>
>>>> Regards,
>>>> Caspar Duregger
>>>>
>>>