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