Theodore Tso <tytso@xxxxxxx> writes:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
