Linus Torvalds  writes:
> For example, a command like "git pull" will leave a special magic name

quoted text
> 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