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

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