* 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
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 NNTP newsgroup(s).