From: Shawn Pearce <spearce@spearce.org>
Date: Fri, 17 Nov 2006 16:26:05 GMT
Subject: Re: multi-project repos (was Re: Cleaning up git user-interface warts)
Message-ID: <20061117162605.GA32597@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0611161039160.3349@woody.osdl.org>

Linus Torvalds <torvalds@osdl.org> wrote:
>  - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge 
>    (or some other operations, like "git rebase" and "git reset": think of 
>    it as a "original head before we did some uncontrolled operation 
>    where we otherwise can't use HEAD^ or similar")
> 
>    I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see 
>    when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a 
>    pull I've done. This is important exactly because ORIG_HEAD is _not_ 
>    the same as the first parent of a merge, since a merge could have been 
>    just a fast-forward.

Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:

	gitk HEAD@{1}..

as recent Git understands that to mean the value that HEAD just had,
which is also what is in ORIG_HEAD.  Except that unlike ORIG_HEAD
it can also show even older values (e.g. HEAD@{3}, 3 ops back)
and it works very, very well on tracking branches.  "What did I
just fetch in next?" `git log next@{1}..next`

--