The commit log message for the feature made it sound as if this is a saner
version of --mixed, but the use case presented makes it clear that it is a
better variant of --hard when your changes and somebody else's changes are
mixed together.
Perhaps we would want to rewrite the example that shows the use of --hard
not to talk about recovering from a failed merge?
Signed-off-by: Junio C Hamano <gitster@pobox.com>
switched to. Any changes to tracked files in the working tree
since <commit> are lost.
--merge::
Resets the index to match the tree recorded by the named commit,
and updates the files that are different between the named commit
and the current commit in the working tree.
-q::
Be quiet, only report errors.
@ -152,6 +157,28 @@ tip of the current branch in ORIG_HEAD, so resetting hard to it
@@ -152,6 +157,28 @@ tip of the current branch in ORIG_HEAD, so resetting hard to it
brings your index file and the working tree back to that state,
and resets the tip of the branch to that commit.
Undo a merge or pull inside a dirty work tree::
+
------------
$ git pull <1>
Auto-merging nitfol
Merge made by recursive.
nitfol | 20 +++++----
...
$ git reset --merge ORIG_HEAD <2>
------------
+
<1> Even if you may have local modifications in your
working tree, you can safely say "git pull" when you know
that the change in the other branch does not overlap with
them.
<2> After inspecting the result of the merge, you may find
that the change in the other branch is unsatisfactory. Running
"git reset --hard ORIG_HEAD" will let you go back to where you
were, but it will discard your local changes, which you do not
want. "git reset --merge" keeps your local changes.
Interrupted workflow::
+
Suppose you are interrupted by an urgent fix request while you
Junio C Hamano
16 years ago