From: Phillip Wood <phillip.wood123@gmail.com>
Date: Mon, 26 Oct 2020 16:42:53 GMT
Subject: Re: ORIG_HEAD after rebase is confusing
Message-ID: <9c763498-ddb9-5fbf-89d8-61dbcf16cb67@gmail.com>
In-Reply-To: <CAFzd1+6hLxHk4FDh0d3AFtRLTbGfuQCsXTNCDfjrzBedPuZ-Gg@mail.gmail.com>

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