Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html