On 10/29/10 01:38, Jonathan Nieder wrote: > With its new semantics, "git reset --merge" is more suitable for > undoing a failed merge than "git reset --hard" is. It is especially > nice if you forget that you are in a merge and make a change or two: > > git merge something-complicated > ... notice conflicts, walk away ... > vi foo.c > git commit; # fails because the index has unmerged entries > git reset --merge > > The modern (post-1.7.0) semantics of git reset --merge ensure that > the changes to foo.c will be preserved by this sequence of commands, > unless foo.c was one of the files with conflicts. > > So in the spirit of ed4a6baa (Documentation: suggest `reset --merge` > in How Merge Works section, 2010-01-23), recommend it in place of > "reset --hard". > > One caveat: for habitual adders-to-index, "git reset --merge" is > no better than "git reset --hard" (though still no worse). > > vi foo.c > git add -u > git diff --cached --check; # fails because conflict markers are present > git reset --merge; # equivalent to git reset --hard > Would it also be a good idea to fill in the hint in git status for the in_merge case with similar information? -- 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