* ORIG_HEAD after rebase is confusing
@ 2020-10-22 20:31 herr.kaste
2020-10-26 10:43 ` Phillip Wood
0 siblings, 1 reply; 5+ messages in thread
From: herr.kaste @ 2020-10-22 20:31 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ORIG_HEAD after rebase is confusing
2020-10-22 20:31 ORIG_HEAD after rebase is confusing herr.kaste
@ 2020-10-26 10:43 ` Phillip Wood
2020-10-26 11:29 ` herr.kaste
0 siblings, 1 reply; 5+ messages in thread
From: Phillip Wood @ 2020-10-26 10:43 UTC (permalink / raw)
To: herr.kaste, git
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ORIG_HEAD after rebase is confusing
2020-10-26 10:43 ` Phillip Wood
@ 2020-10-26 11:29 ` herr.kaste
2020-10-26 11:45 ` herr.kaste
0 siblings, 1 reply; 5+ messages in thread
From: herr.kaste @ 2020-10-26 11:29 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
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
> >
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ORIG_HEAD after rebase is confusing
2020-10-26 11:29 ` herr.kaste
@ 2020-10-26 11:45 ` herr.kaste
2020-10-26 16:42 ` Phillip Wood
0 siblings, 1 reply; 5+ messages in thread
From: herr.kaste @ 2020-10-26 11:45 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
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>:
>
> 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
> > >
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ORIG_HEAD after rebase is confusing
2020-10-26 11:45 ` herr.kaste
@ 2020-10-26 16:42 ` Phillip Wood
0 siblings, 0 replies; 5+ messages in thread
From: Phillip Wood @ 2020-10-26 16:42 UTC (permalink / raw)
To: herr.kaste; +Cc: git
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
>>>>
>>>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-26 16:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-22 20:31 ORIG_HEAD after rebase is confusing herr.kaste
2020-10-26 10:43 ` Phillip Wood
2020-10-26 11:29 ` herr.kaste
2020-10-26 11:45 ` herr.kaste
2020-10-26 16:42 ` Phillip Wood
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).