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