Re: ORIG_HEAD after rebase is confusing

Phillip Wood <phillip.wood123@xxxxxxxxx> · Mon, 26 Oct 2020 16:42:53 +0000

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

`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@xxxxxxxxx>:

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@xxxxxxxxx>:

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