Re: ORIG_HEAD after rebase is confusing

From: herr.kaste <herr.kaste@gmail.com>
Date: Oct 26, 2020, 11:29 UTC
Message-ID: <CAFzd1+7PDg2PZgKw7U0kdepdYuoML9wSN4kofmB_-8NHrbbrHg@mail.gmail.com>
In-Reply-To: <8bb82be6-dc51-6602-47b5-c849a87ae55e@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>:

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