Re: [RFC 0/3] Make git more user-friendly during a merge conflict

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Mar 1, 2014, 11:38 UTC
Message-ID: <vpqioryrvwg.fsf@anie.imag.fr>
In-Reply-To: <85vbvyxl8i.fsf@stephe-leake.org>

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> So as I understand it, this does _not_ lose your conflict resolutions.

Well, then maybe it's time to try the command before continuing commenting on its behavior ;-).

$ git status
[...]
        both modified:      foo.txt
[...]
$ git diff
diff --cc foo.txt
index 595f399,996c0e1..0000000

--- a/foo.txt
+++ b/foo.txt
@@@ -1,1 -1,1 +1,1 @@@
- content1
 -content2
++resolved
$ git reset --merge
$ git status
On branch master
nothing to commit, working directory clean
$

> In fact, it now seems that 'git reset --mixed' is always the same as
> 'git reset --merge'. So I must be missing something!

"git reset --merge" is an alias for "git merge --abort" (IIRC, it's
actually the other way around). Essentially, it reverts, or tries to
revert everything (worktree and index) as it was before the merge. That
includes throwing away conflict resolution.

Now, I do agree that the documentation of "git reset" is terrible, and I
actually think that the command does too many different things (putting
"git reset" and "git reset --hard" so close to each other is not a good
idead IMHO: the first is a harmless command I use very often, and the
second is one of the most destructive operation Git has).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/