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

From: Theodore Tso <tytso@mit.edu>
Date: Jul 7, 2008, 11:18 UTC
Message-ID: <20080707111803.GF31490@mit.edu>
In-Reply-To: <7vbq1a8ay3.fsf@gitster.siamese.dyndns.org>

On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

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

One of the things that's been on my 'twoud be nice list is having an option to "git reflog show" which prints the timestamp associated with each reflog entry, since tools like guilt tend to create quite a few reflog entries, and looking at the time stamps is one of the easier ways to disentangle it. For now what I tend to do is expand my terminal window so it's super wide, and then look at the raw .git/logs/HEAD file directly.

						- Ted