Re: git rebase: retain original head?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 9, 2019, 14:05 UTC
Message-ID: <nycvar.QRO.7.76.6.1901091501320.41@tvgsbejvaqbjf.bet>
In-Reply-To: <CA+P7+xq++4W32JT9WcasXn=Oj9W-U1eteFgpLZn8GVqeO0foog@mail.gmail.com>

Hi Jake,

On Tue, 8 Jan 2019, Jacob Keller wrote:

Show 35 quoted lines

> On Tue, Jan 8, 2019 at 12:47 PM Markus Wiederkehr
> <markus.wiederkehr@gmail.com> wrote:
> >
> > On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> > >
> > > On Jan 08 2019, Markus Wiederkehr <markus.wiederkehr@gmail.com> wrote:
> > >
> > > > Would it be possible to retain this information?
> > >
> > > You could use the reflog of the current branch, where it is the second
> > > entry.
> >
> > It is not, depending on what happens in the rebase it could be any
> > entry. That's why I always have to search for the right one, which is
> > tedious.
> >
> > Example:
> >
> > $ git rebase -i root-tag
> > ... (apply one fixup)
> > $ git reflog
> > 906caf1c (HEAD -> master) HEAD@{0}: rebase -i (finish): returning to
> > refs/heads/master
> > 4906caf1c (HEAD -> master) HEAD@{1}: rebase -i (pick): qux
> > 85dab37b4 HEAD@{2}: rebase -i (pick): baz
> > 7de7420d2 HEAD@{3}: rebase -i (fixup): bar
> > 9bc0461c0 HEAD@{4}: rebase -i (start): checkout root-tag
> > a150b73ca HEAD@{5}: commit: foo
> >
> > Here I have to use HEAD@{5}.
> >
> 
> He meant using:
> 
> $ git reflog master

Indeed. That's why terse answers are often worse than no answers at all: more often than not, they leave things unclearer than before, in the worst case they are misleading, as was the very terse first reply. Just don't. Too short is not beautiful.

Show 7 quoted lines

> which only shows changes directly to the master ref, not to HEAD.
> During a git rebase operations don't modify the master ref until after
> the rebase finishes. This, of course, assumes you're on a branch.
> 
> If so, you should even be able to use master@{1} and be safe in
> assuming it always refers to what the branch was before the rebase
> started.

There are more tricks up Git's sleeves: @{1} is a shorthand for the previous state of the current branch (if any). So after you rebase a branch, @{1} will refer to what previously was ORIG_HEAD.

Having said that, it is an unintended regression in the built-in rebase. Markus, could you come up with a minimal test case, preferably in the form of a patch to t/t3415-rebase-autosquash.sh?

Thanks, Johannes