{"thread":{"id":"54487","subject":"ORIG_HEAD after rebase is confusing","startedAt":"2020-10-22T20:31:51Z","lastAt":"2020-10-26T16:46:36Z","messageCount":5,"participants":["herr.kaste","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"408189","messageId":"CAFzd1+62PmHBoVpMw-y4TC=bmc8N0wDpF2jQa7XGz2e+7Dos6A@mail.gmail.com","threadId":"54487","inReplyTo":null,"subject":"ORIG_HEAD after rebase is confusing","fromName":"herr.kaste","fromEmail":"herr.kaste@gmail.com","sentAt":"2020-10-22T20:31:22Z","receivedAt":"2020-10-22T20:31:51Z","isPatch":false,"sender":{"key":"herr.kaste@gmail.com","avatar":null},"body":"Reading the git rebase manual and some answer on stackoverflow I assumed\n`ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*\nI started rebasing.  But it doesn't seem so.\n\nFor example, I have this:\n\n\n  $ git log --graph --all --oneline\n  * 9830f9f (master) X\n  | * fb7b6a6 (HEAD -> feature) D\n  | * 46b7a7a C\n  | * da5e4c7 B\n  | * 5c135da A\n  |/\n  * 6848823 Init\n\n  $ git rebase master\n  Successfully rebased and updated refs/heads/feature.\n\n  $ git rev-parse ORIG_HEAD\n  da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7\n\n  $ git reflog\n  a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to\nrefs/heads/feature\n  a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D\n  2f458e8 HEAD@{2}: rebase (pick): C\n  0aa2160 HEAD@{3}: rebase (pick): B\n  b957fc7 HEAD@{4}: rebase (pick): A\n  9830f9f (master) HEAD@{5}: rebase (start): checkout master\n  fb7b6a6 HEAD@{6}: checkout: moving from master to feature\n  9830f9f (master) HEAD@{7}: commit: X\n  6848823 HEAD@{8}: checkout: moving from feature to master\n  fb7b6a6 HEAD@{9}: commit: D\n  46b7a7a HEAD@{10}: commit: C\n  da5e4c7 HEAD@{11}: commit: B\n  5c135da HEAD@{12}: commit: A\n  6848823 HEAD@{13}: checkout: moving from master to feature\n  6848823 HEAD@{14}: commit (initial): Init\n\nSo `ORIG_HEAD` here points to the original B commit.  (I expected the D.)\nHonestly, this doesn't make much sense to me in that I don't know *why* it\neven chooses B which is a middle commit in the chain.  (And from reading the\nsource `sequencer.c` I can't deduce it either.)\n\n  $ git --version\n  git version 2.29.0.windows.1\n\nWhat I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for\nexample `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge\nconflict.\n\n\nRegards,\nCaspar Duregger\n"},{"id":"408386","messageId":"8bb82be6-dc51-6602-47b5-c849a87ae55e@gmail.com","threadId":"54487","inReplyTo":"CAFzd1+62PmHBoVpMw-y4TC=bmc8N0wDpF2jQa7XGz2e+7Dos6A@mail.gmail.com","subject":"Re: ORIG_HEAD after rebase is confusing","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-26T10:43:22Z","receivedAt":"2020-10-26T10:43:29Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Caspar\n\nOn 22/10/2020 21:31, herr.kaste wrote:\n> Reading the git rebase manual and some answer on stackoverflow I assumed\n> `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*\n> I started rebasing.  But it doesn't seem so.\n> \n> For example, I have this:\n> \n> \n>    $ git log --graph --all --oneline\n>    * 9830f9f (master) X\n>    | * fb7b6a6 (HEAD -> feature) D\n>    | * 46b7a7a C\n>    | * da5e4c7 B\n>    | * 5c135da A\n>    |/\n>    * 6848823 Init\n> \n>    $ git rebase master\n>    Successfully rebased and updated refs/heads/feature.\n> \n>    $ git rev-parse ORIG_HEAD\n>    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7\n> \n>    $ git reflog\n>    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to\n> refs/heads/feature\n>    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D\n>    2f458e8 HEAD@{2}: rebase (pick): C\n>    0aa2160 HEAD@{3}: rebase (pick): B\n>    b957fc7 HEAD@{4}: rebase (pick): A\n>    9830f9f (master) HEAD@{5}: rebase (start): checkout master\n>    fb7b6a6 HEAD@{6}: checkout: moving from master to feature\n>    9830f9f (master) HEAD@{7}: commit: X\n>    6848823 HEAD@{8}: checkout: moving from feature to master\n>    fb7b6a6 HEAD@{9}: commit: D\n>    46b7a7a HEAD@{10}: commit: C\n>    da5e4c7 HEAD@{11}: commit: B\n>    5c135da HEAD@{12}: commit: A\n>    6848823 HEAD@{13}: checkout: moving from master to feature\n>    6848823 HEAD@{14}: commit (initial): Init\n> \n> So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)\n\nIt should be D, unless you ran `git reset` or `git rebase --skip` while \nyou were rebasing as they also update ORIG_HEAD\n\n> Honestly, this doesn't make much sense to me in that I don't know *why* it\n> even chooses B which is a middle commit in the chain.  (And from reading the\n> source `sequencer.c` I can't deduce it either.)\n> \n>    $ git --version\n>    git version 2.29.0.windows.1\n> \n> What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for\n> example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge\n> conflict.\n\nAfter you rebase you can user feature@{1} to get the head of feature \nbefore rebasing (until you make another commit on feature)\n\nBest Wishes\n\nPhillip\n\n> Regards,\n> Caspar Duregger\n> \n\n"},{"id":"408387","messageId":"CAFzd1+7PDg2PZgKw7U0kdepdYuoML9wSN4kofmB_-8NHrbbrHg@mail.gmail.com","threadId":"54487","inReplyTo":"8bb82be6-dc51-6602-47b5-c849a87ae55e@gmail.com","subject":"Re: ORIG_HEAD after rebase is confusing","fromName":"herr.kaste","fromEmail":"herr.kaste@gmail.com","sentAt":"2020-10-26T11:29:13Z","receivedAt":"2020-10-26T11:29:40Z","isPatch":false,"sender":{"key":"herr.kaste@gmail.com","avatar":null},"body":"Hi Philipp,\n\nfor whatever reason that doesn't work.  I know the `feature@{1}` trick\nbut hoped just `ORIG_HEAD` would work.  Or maybe it used to work, it's not\nan everyday command.\n\nFollowing is my test case:\n\n    $ git init; git commit --allow-empty -m \"Init\"\n    [master (root-commit) 5db5264] Init\n\n    c-flo@KLOG MINGW64 /d/rebtest (master)\n    $ git co -b feature\n    Switched to a new branch 'feature'\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git commit --allow-empty -m \"A\"\n    [feature 5c7dfb4] A\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git commit --allow-empty -m \"B\"\n    [feature a61bd4c] B\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git commit --allow-empty -m \"C\"\n    [feature 26e6417] C\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git commit --allow-empty -m \"D\"\n    [feature 735e4fb] D\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git co master\n    Switched to branch 'master'\n\n    c-flo@KLOG MINGW64 /d/rebtest (master)\n    $ git commit --allow-empty -m \"X\"\n    [master 3eb6a3f] X\n\n    c-flo@KLOG MINGW64 /d/rebtest (master)\n    $ git co feature\n    Switched to branch 'feature'\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git rev-parse ORIG_HEAD\n    fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path\nnot in the working tree.\n    Use '--' to separate paths from revisions, like this:\n    'git <command> [<revision>...] -- [<file>...]'\n    ORIG_HEAD\n\nIntentional, up to this point I did nothing that sets `ORIG_HEAD`.\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git rebase master\n    Successfully rebased and updated refs/heads/feature.\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git rev-parse ORIG_HEAD\n    a61bd4c550396ac086879aea829375d839a1667b\n\n    c-flo@KLOG MINGW64 /d/rebtest (feature)\n    $ git rev-parse feature@{1}\n    735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d\n\nSo here again, `ORIG_HEAD` points to the original B.  And `feature@{1}`\ncorrectly points to the original D.  I obviously did no `rebase --skip`\nhere.  Is there an internal `git --reset` somewhere here I'm missing?\n\nAnyhow, you said it should work unless there is an `git --reset` or\n`--skip` **while** rebasing.  So I guess the relatively declarative\nusage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone\nfor example if I use `-i --rebase-merges`.\n\nThat is, I actually wonder if you set `ORIG_HEAD` more at the start of the\nrebasing work, or basically in the cleanup function of the rebase, e.g. when you\ndelete the `orig-head` file.  It looks like the former, and I assumed\nthe latter.\n\n\nRegards,\nCaspar Duregger\n\nAm Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood\n<phillip.wood123@gmail.com>:\n>\n> Hi Caspar\n>\n> On 22/10/2020 21:31, herr.kaste wrote:\n> > Reading the git rebase manual and some answer on stackoverflow I assumed\n> > `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*\n> > I started rebasing.  But it doesn't seem so.\n> >\n> > For example, I have this:\n> >\n> >\n> >    $ git log --graph --all --oneline\n> >    * 9830f9f (master) X\n> >    | * fb7b6a6 (HEAD -> feature) D\n> >    | * 46b7a7a C\n> >    | * da5e4c7 B\n> >    | * 5c135da A\n> >    |/\n> >    * 6848823 Init\n> >\n> >    $ git rebase master\n> >    Successfully rebased and updated refs/heads/feature.\n> >\n> >    $ git rev-parse ORIG_HEAD\n> >    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7\n> >\n> >    $ git reflog\n> >    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to\n> > refs/heads/feature\n> >    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D\n> >    2f458e8 HEAD@{2}: rebase (pick): C\n> >    0aa2160 HEAD@{3}: rebase (pick): B\n> >    b957fc7 HEAD@{4}: rebase (pick): A\n> >    9830f9f (master) HEAD@{5}: rebase (start): checkout master\n> >    fb7b6a6 HEAD@{6}: checkout: moving from master to feature\n> >    9830f9f (master) HEAD@{7}: commit: X\n> >    6848823 HEAD@{8}: checkout: moving from feature to master\n> >    fb7b6a6 HEAD@{9}: commit: D\n> >    46b7a7a HEAD@{10}: commit: C\n> >    da5e4c7 HEAD@{11}: commit: B\n> >    5c135da HEAD@{12}: commit: A\n> >    6848823 HEAD@{13}: checkout: moving from master to feature\n> >    6848823 HEAD@{14}: commit (initial): Init\n> >\n> > So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)\n>\n> It should be D, unless you ran `git reset` or `git rebase --skip` while\n> you were rebasing as they also update ORIG_HEAD\n>\n> > Honestly, this doesn't make much sense to me in that I don't know *why* it\n> > even chooses B which is a middle commit in the chain.  (And from reading the\n> > source `sequencer.c` I can't deduce it either.)\n> >\n> >    $ git --version\n> >    git version 2.29.0.windows.1\n> >\n> > What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for\n> > example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge\n> > conflict.\n>\n> After you rebase you can user feature@{1} to get the head of feature\n> before rebasing (until you make another commit on feature)\n>\n> Best Wishes\n>\n> Phillip\n>\n> > Regards,\n> > Caspar Duregger\n> >\n>\n"},{"id":"408388","messageId":"CAFzd1+6hLxHk4FDh0d3AFtRLTbGfuQCsXTNCDfjrzBedPuZ-Gg@mail.gmail.com","threadId":"54487","inReplyTo":"CAFzd1+7PDg2PZgKw7U0kdepdYuoML9wSN4kofmB_-8NHrbbrHg@mail.gmail.com","subject":"Re: ORIG_HEAD after rebase is confusing","fromName":"herr.kaste","fromEmail":"herr.kaste@gmail.com","sentAt":"2020-10-26T11:45:35Z","receivedAt":"2020-10-26T11:46:04Z","isPatch":false,"sender":{"key":"herr.kaste@gmail.com","avatar":null},"body":"Sorry, Phillip not Philipp.\n\nThere is a bug here I think.  The following works as expected, t.i.\n`ORIG_HEAD == feature@{1}`.\n\n    git init\n    git commit --allow-empty -m \"Init\"\n    git co -b feature\n    git commit --allow-empty -m \"A\"\n    git commit --allow-empty -m \"B\"\n    git commit --allow-empty -m \"C\"\n    git commit --allow-empty -m \"D\"\n    git commit --allow-empty -m \"E\"\n    git commit --allow-empty -m \"F\"\n    git co master\n    git commit --allow-empty -m \"X\"\n    git co feature\n    git rebase master\n    git rev-parse ORIG_HEAD\n    git rev-parse feature@{1}\n\nBut if you omit commit `F` or both `F` and `E` it doesn't.\n\nRegards,\nCaspar Duregger\n\n\nAm Mo., 26. Okt. 2020 um 12:29 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:\n>\n> Hi Philipp,\n>\n> for whatever reason that doesn't work.  I know the `feature@{1}` trick\n> but hoped just `ORIG_HEAD` would work.  Or maybe it used to work, it's not\n> an everyday command.\n>\n> Following is my test case:\n>\n>     $ git init; git commit --allow-empty -m \"Init\"\n>     [master (root-commit) 5db5264] Init\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (master)\n>     $ git co -b feature\n>     Switched to a new branch 'feature'\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git commit --allow-empty -m \"A\"\n>     [feature 5c7dfb4] A\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git commit --allow-empty -m \"B\"\n>     [feature a61bd4c] B\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git commit --allow-empty -m \"C\"\n>     [feature 26e6417] C\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git commit --allow-empty -m \"D\"\n>     [feature 735e4fb] D\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git co master\n>     Switched to branch 'master'\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (master)\n>     $ git commit --allow-empty -m \"X\"\n>     [master 3eb6a3f] X\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (master)\n>     $ git co feature\n>     Switched to branch 'feature'\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git rev-parse ORIG_HEAD\n>     fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path\n> not in the working tree.\n>     Use '--' to separate paths from revisions, like this:\n>     'git <command> [<revision>...] -- [<file>...]'\n>     ORIG_HEAD\n>\n> Intentional, up to this point I did nothing that sets `ORIG_HEAD`.\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git rebase master\n>     Successfully rebased and updated refs/heads/feature.\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git rev-parse ORIG_HEAD\n>     a61bd4c550396ac086879aea829375d839a1667b\n>\n>     c-flo@KLOG MINGW64 /d/rebtest (feature)\n>     $ git rev-parse feature@{1}\n>     735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d\n>\n> So here again, `ORIG_HEAD` points to the original B.  And `feature@{1}`\n> correctly points to the original D.  I obviously did no `rebase --skip`\n> here.  Is there an internal `git --reset` somewhere here I'm missing?\n>\n> Anyhow, you said it should work unless there is an `git --reset` or\n> `--skip` **while** rebasing.  So I guess the relatively declarative\n> usage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone\n> for example if I use `-i --rebase-merges`.\n>\n> That is, I actually wonder if you set `ORIG_HEAD` more at the start of the\n> rebasing work, or basically in the cleanup function of the rebase, e.g. when you\n> delete the `orig-head` file.  It looks like the former, and I assumed\n> the latter.\n>\n>\n> Regards,\n> Caspar Duregger\n>\n> Am Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood\n> <phillip.wood123@gmail.com>:\n> >\n> > Hi Caspar\n> >\n> > On 22/10/2020 21:31, herr.kaste wrote:\n> > > Reading the git rebase manual and some answer on stackoverflow I assumed\n> > > `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*\n> > > I started rebasing.  But it doesn't seem so.\n> > >\n> > > For example, I have this:\n> > >\n> > >\n> > >    $ git log --graph --all --oneline\n> > >    * 9830f9f (master) X\n> > >    | * fb7b6a6 (HEAD -> feature) D\n> > >    | * 46b7a7a C\n> > >    | * da5e4c7 B\n> > >    | * 5c135da A\n> > >    |/\n> > >    * 6848823 Init\n> > >\n> > >    $ git rebase master\n> > >    Successfully rebased and updated refs/heads/feature.\n> > >\n> > >    $ git rev-parse ORIG_HEAD\n> > >    da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7\n> > >\n> > >    $ git reflog\n> > >    a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to\n> > > refs/heads/feature\n> > >    a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D\n> > >    2f458e8 HEAD@{2}: rebase (pick): C\n> > >    0aa2160 HEAD@{3}: rebase (pick): B\n> > >    b957fc7 HEAD@{4}: rebase (pick): A\n> > >    9830f9f (master) HEAD@{5}: rebase (start): checkout master\n> > >    fb7b6a6 HEAD@{6}: checkout: moving from master to feature\n> > >    9830f9f (master) HEAD@{7}: commit: X\n> > >    6848823 HEAD@{8}: checkout: moving from feature to master\n> > >    fb7b6a6 HEAD@{9}: commit: D\n> > >    46b7a7a HEAD@{10}: commit: C\n> > >    da5e4c7 HEAD@{11}: commit: B\n> > >    5c135da HEAD@{12}: commit: A\n> > >    6848823 HEAD@{13}: checkout: moving from master to feature\n> > >    6848823 HEAD@{14}: commit (initial): Init\n> > >\n> > > So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)\n> >\n> > It should be D, unless you ran `git reset` or `git rebase --skip` while\n> > you were rebasing as they also update ORIG_HEAD\n> >\n> > > Honestly, this doesn't make much sense to me in that I don't know *why* it\n> > > even chooses B which is a middle commit in the chain.  (And from reading the\n> > > source `sequencer.c` I can't deduce it either.)\n> > >\n> > >    $ git --version\n> > >    git version 2.29.0.windows.1\n> > >\n> > > What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for\n> > > example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge\n> > > conflict.\n> >\n> > After you rebase you can user feature@{1} to get the head of feature\n> > before rebasing (until you make another commit on feature)\n> >\n> > Best Wishes\n> >\n> > Phillip\n> >\n> > > Regards,\n> > > Caspar Duregger\n> > >\n> >\n"},{"id":"408406","messageId":"9c763498-ddb9-5fbf-89d8-61dbcf16cb67@gmail.com","threadId":"54487","inReplyTo":"CAFzd1+6hLxHk4FDh0d3AFtRLTbGfuQCsXTNCDfjrzBedPuZ-Gg@mail.gmail.com","subject":"Re: ORIG_HEAD after rebase is confusing","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-10-26T16:42:53Z","receivedAt":"2020-10-26T16:46:36Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Capsar\n\nOn 26/10/2020 11:45, herr.kaste wrote:\n> Sorry, Phillip not Philipp.\n >\n> There is a bug here I think.  The following works as expected, t.i.\n\nYes there is a bug - we are overwriting a statically allocated buffer \nholding the abbreviated OID, thanks for the reproduction recipe. I've \ngot a fix locally, I'll clean it up and post it in the next couple of days.\n\nBest Wishes\n\nPhillip\n\n> `ORIG_HEAD == feature@{1}`.\n> \n>      git init\n>      git commit --allow-empty -m \"Init\"\n>      git co -b feature\n>      git commit --allow-empty -m \"A\"\n>      git commit --allow-empty -m \"B\"\n>      git commit --allow-empty -m \"C\"\n>      git commit --allow-empty -m \"D\"\n>      git commit --allow-empty -m \"E\"\n>      git commit --allow-empty -m \"F\"\n>      git co master\n>      git commit --allow-empty -m \"X\"\n>      git co feature\n>      git rebase master\n>      git rev-parse ORIG_HEAD\n>      git rev-parse feature@{1}\n> \n> But if you omit commit `F` or both `F` and `E` it doesn't.\n> \n> Regards,\n> Caspar Duregger\n> \n> \n> Am Mo., 26. Okt. 2020 um 12:29 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:\n>>\n>> Hi Philipp,\n>>\n>> for whatever reason that doesn't work.  I know the `feature@{1}` trick\n>> but hoped just `ORIG_HEAD` would work.  Or maybe it used to work, it's not\n>> an everyday command.\n>>\n>> Following is my test case:\n>>\n>>      $ git init; git commit --allow-empty -m \"Init\"\n>>      [master (root-commit) 5db5264] Init\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (master)\n>>      $ git co -b feature\n>>      Switched to a new branch 'feature'\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git commit --allow-empty -m \"A\"\n>>      [feature 5c7dfb4] A\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git commit --allow-empty -m \"B\"\n>>      [feature a61bd4c] B\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git commit --allow-empty -m \"C\"\n>>      [feature 26e6417] C\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git commit --allow-empty -m \"D\"\n>>      [feature 735e4fb] D\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git co master\n>>      Switched to branch 'master'\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (master)\n>>      $ git commit --allow-empty -m \"X\"\n>>      [master 3eb6a3f] X\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (master)\n>>      $ git co feature\n>>      Switched to branch 'feature'\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git rev-parse ORIG_HEAD\n>>      fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path\n>> not in the working tree.\n>>      Use '--' to separate paths from revisions, like this:\n>>      'git <command> [<revision>...] -- [<file>...]'\n>>      ORIG_HEAD\n>>\n>> Intentional, up to this point I did nothing that sets `ORIG_HEAD`.\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git rebase master\n>>      Successfully rebased and updated refs/heads/feature.\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git rev-parse ORIG_HEAD\n>>      a61bd4c550396ac086879aea829375d839a1667b\n>>\n>>      c-flo@KLOG MINGW64 /d/rebtest (feature)\n>>      $ git rev-parse feature@{1}\n>>      735e4fbd14b9ef8b3f2156f1ed90dbde3742d65d\n>>\n>> So here again, `ORIG_HEAD` points to the original B.  And `feature@{1}`\n>> correctly points to the original D.  I obviously did no `rebase --skip`\n>> here.  Is there an internal `git --reset` somewhere here I'm missing?\n>>\n>> Anyhow, you said it should work unless there is an `git --reset` or\n>> `--skip` **while** rebasing.  So I guess the relatively declarative\n>> usage of `ORIG_HEAD` I'm after, for example `reset ORIG_HEAD`, is error-prone\n>> for example if I use `-i --rebase-merges`.\n>>\n>> That is, I actually wonder if you set `ORIG_HEAD` more at the start of the\n>> rebasing work, or basically in the cleanup function of the rebase, e.g. when you\n>> delete the `orig-head` file.  It looks like the former, and I assumed\n>> the latter.\n>>\n>>\n>> Regards,\n>> Caspar Duregger\n>>\n>> Am Mo., 26. Okt. 2020 um 11:43 Uhr schrieb Phillip Wood\n>> <phillip.wood123@gmail.com>:\n>>>\n>>> Hi Caspar\n>>>\n>>> On 22/10/2020 21:31, herr.kaste wrote:\n>>>> Reading the git rebase manual and some answer on stackoverflow I assumed\n>>>> `ORIG_HEAD` will point to the original HEAD, the tip of the branch *before*\n>>>> I started rebasing.  But it doesn't seem so.\n>>>>\n>>>> For example, I have this:\n>>>>\n>>>>\n>>>>     $ git log --graph --all --oneline\n>>>>     * 9830f9f (master) X\n>>>>     | * fb7b6a6 (HEAD -> feature) D\n>>>>     | * 46b7a7a C\n>>>>     | * da5e4c7 B\n>>>>     | * 5c135da A\n>>>>     |/\n>>>>     * 6848823 Init\n>>>>\n>>>>     $ git rebase master\n>>>>     Successfully rebased and updated refs/heads/feature.\n>>>>\n>>>>     $ git rev-parse ORIG_HEAD\n>>>>     da5e4c7e9eb3b10c1efa08c534b9c9e4b92d9fd7\n>>>>\n>>>>     $ git reflog\n>>>>     a647bd7 (HEAD -> feature) HEAD@{0}: rebase (finish): returning to\n>>>> refs/heads/feature\n>>>>     a647bd7 (HEAD -> feature) HEAD@{1}: rebase (pick): D\n>>>>     2f458e8 HEAD@{2}: rebase (pick): C\n>>>>     0aa2160 HEAD@{3}: rebase (pick): B\n>>>>     b957fc7 HEAD@{4}: rebase (pick): A\n>>>>     9830f9f (master) HEAD@{5}: rebase (start): checkout master\n>>>>     fb7b6a6 HEAD@{6}: checkout: moving from master to feature\n>>>>     9830f9f (master) HEAD@{7}: commit: X\n>>>>     6848823 HEAD@{8}: checkout: moving from feature to master\n>>>>     fb7b6a6 HEAD@{9}: commit: D\n>>>>     46b7a7a HEAD@{10}: commit: C\n>>>>     da5e4c7 HEAD@{11}: commit: B\n>>>>     5c135da HEAD@{12}: commit: A\n>>>>     6848823 HEAD@{13}: checkout: moving from master to feature\n>>>>     6848823 HEAD@{14}: commit (initial): Init\n>>>>\n>>>> So `ORIG_HEAD` here points to the original B commit.  (I expected the D.)\n>>>\n>>> It should be D, unless you ran `git reset` or `git rebase --skip` while\n>>> you were rebasing as they also update ORIG_HEAD\n>>>\n>>>> Honestly, this doesn't make much sense to me in that I don't know *why* it\n>>>> even chooses B which is a middle commit in the chain.  (And from reading the\n>>>> source `sequencer.c` I can't deduce it either.)\n>>>>\n>>>>     $ git --version\n>>>>     git version 2.29.0.windows.1\n>>>>\n>>>> What I actually wanted to do was `git reset --hard ORIG_HEAD` fwiw.  And for\n>>>> example `git diff HEAD..ORIG_HEAD` to check for unwanted changes after a merge\n>>>> conflict.\n>>>\n>>> After you rebase you can user feature@{1} to get the head of feature\n>>> before rebasing (until you make another commit on feature)\n>>>\n>>> Best Wishes\n>>>\n>>> Phillip\n>>>\n>>>> Regards,\n>>>> Caspar Duregger\n>>>>\n>>>\n"}]}