Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 7, 2008, 11:42 UTC
Message-ID: <m34p71gbuk.fsf@localhost.localdomain>
In-Reply-To: <20080707111803.GF31490@mit.edu>

Theodore Tso <tytso@MIT.EDU> writes:

Show 22 quoted lines

> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:
> > The idea behind ORIG_HEAD is to have an anchoring point before an
> > operation that moves your HEAD in a drastic way.  Think if it as a
> > poor-man's reflog -- in fact it predates reflog.
> > 
> > That is why reset saves away the HEAD before it does its thing, so that
> > you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip
> > back to the previous state.  Both a fast-forward merge and a real merge
> > can be undone by resetting back to ORIG_HEAD.
> > 
> > So in that sense:
> > 
> >  (1) ORIG_HEAD is not strictly necessary these days, because we have
> >      reflogs;
> 
> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
> be pointing out HEAD before the user typed pretty much any git
> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
> it you have to paw through multiple HEAD@{n} to find the 'n' which
> corresponds to state before executing the git plumbing command, since
> multiple git plumbing commands could have updated the HEAD's reflog,
> right?

You can always use _branch_ reflog, either in the <branch>@{1} form, or in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD even for rebase.

-- 
Jakub Narebski
Poland
ShadeHawk on #git