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