Re: Git rescue mission

From: Kalle Pokki <kalle.pokki@iki.fi>
Date: Feb 8, 2007, 20:12 UTC
Message-ID: <87fy9gz9vu.fsf@host94.eke.fi>
In-Reply-To: <Pine.LNX.4.64.0702080858430.8424@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 11 quoted lines

> For example, a command like "git pull" will leave a special magic name 
> around to tell you what the original HEAD was before the pull, and that 
> magic name is (surprise surprise) called ORIG_HEAD. So if the pull 
> succeeded, but you realized it was an error (perhaps you had even intended 
> to do it, but once you pulled, you just saw that what you pulled was crap, 
> so you decide that you didn't really want to do it after all), you can 
> just do
> 
> 	git reset --hard ORIG_HEAD
> 
> and you're back to where you were _before_ the pull.

I usually undo a pull by throwing away just the merge commit by

        git reset --hard HEAD^

This seems to always get me back to the head commit I had previously, but I'm wondering would git in some circumstances leave me with the commits I just pulled and throw away my own work instead. Or is it guaranteed that I always reset to the parent commit I had before the pull (i.e. ORIG_HEAD)?

Of course HEAD^ doesn't work the same with fast-forward merges, so it would probably make more sense to just use ORIG_HEAD all the time.