Bug 3105 - Defang 'hg resolve'
Summary: Defang 'hg resolve'
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal feature
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-16 14:10 UTC by Gregg Lind
Modified: 2012-05-13 04:54 UTC (History)
5 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregg Lind 2011-11-16 14:10 UTC
I didn't see any actual bugs / action plan based on the discussion at
http://mercurial.808500.n3.nabble.com/Painful-user-experience-with-hg-resolve-td3285000.html
. 

Me:

* newish hg user
* coming from git
* with internal:merge (conflict markers)

After I 'fix' my conflicts, 'hg resolve' (no args) *undoes the work*.  This
is very pointy!  It's more like 'hg antiresolve' :)  

Solutions (from the thread)

* more documentation (boo!)
* moving resolve (no args) to 'remerge'
* checking for hashes during the merge, or otherwise looking for conflict
markers or something (seems brittle)
Comment 1 Matt Mackall 2011-11-16 14:26 UTC
Degrading to feature: it works precisely as advertised and documented so
it's not a bug.

Renaming command: not a chance, that breaks backwards compatibility rules.
And 'remerge' suggest redoing the entire merge, not just one file. As this
is another common use case, this would create just as much confusion as it
solves.

Improved checking: won't work, just consider the case where you completed
the merge but incorrectly.

More docs: here's what commit says when you've manually fixed up merge
markers but haven't run resolve:

 abort: unresolved merge conflicts (see hg help resolve)

And if you read the help, the first thing it says is:

 redo merges or set/view the merge status of files

This should be no surprise, because 'merge' itself already told you:

 use 'hg resolve' to retry unresolved file merges

So if you run 'hg resolve foo' at this point, no amount of doc improvement
will help you.

Marking done-cbb as I'm not aware of any viable fixes.
Comment 2 Gregg Lind 2011-11-16 16:13 UTC
Field report addendum:  Maybe it's just me, or my history, but it's this
phrase (emphasis mine):

>   use 'hg resolve' to __retry unresolved file merges__

that caused the confusion.  

1) I merged, getting conflict markers
2) fixed them
3) tried to commit, getting errors, mentioning the merge, which to me was
'resolved'
4) tried 'hg resolve' 
5) was annoyed :)

maybe adding 'or, hg resolve -a, if you fixed them yourself' or 
'use 'hg resolve' to retry (start over) unresolved file merges'
  would have saved me from myself here.  

The mental model confusion here for me is 'retry' here means 'retry from
tip' or something, and has nothing to do with the working copy.  My real
breakdown was wondering why ``commit`` wouldn't accept my changes!  I
thought resolve would inform Hg that 'yes I am done' (which it does in the
'-a' form).  I was just bad-surprised that the default command did the
opposite :)

Something didn't click about the model and workflow as a whole, and I got a
bit burned.
Comment 3 Matt Mackall 2011-11-16 16:30 UTC
One thing to be aware of is that the whole workflow is designed around NOT
using '70s-era merge markers. If you use a merge tool, Mercurial knows when
a file is resolved because the merge tool tells it. So using internal:merge
is definitely a special case with limited support. I'd be willing to add a
special message about resolve -m for when internal:merge. Something like:

diff -r 07321142be29 mercurial/filemerge.py
--- a/mercurial/filemerge.py	Sat Nov 12 02:08:01 2011 +0100
+++ b/mercurial/filemerge.py	Wed Nov 16 16:28:38 2011 -0600
@@ -262,7 +262,11 @@
         _matcheol(repo.wjoin(fd), back)
 
     if r:
-        ui.warn(_("merging %s failed!\n") % fd)
+        if tool == "internal:merge":
+            ui.warn(_("merging %s incomplete! "
+                      "(edit conflicts, then use 'hg resolve --mark')\n") % fd)
+        else:
+            ui.warn(_("merging %s failed!\n") % fd)
     else:
         os.unlink(back)
Comment 4 Gregg Lind 2011-11-16 16:47 UTC
You hatred of conflict markers is well-known :)  They do come up, as said in
that thread, and I think your solution is a good one, to have the extra
warning in those cases where 'hand-merging' is likely/possible to happen.  

"edit conflicts, then use 'hg resolve --mark"  is completely clear as to
what to do next.  Thanks for accepting the real world use case on this one.
 I am not sure what people who use external diff/merge tools do.  Vimdiff
tends to be the only one available to me on some platforms where I am
hacking, and I am not always a fan of it!
Comment 5 HG Bot 2011-11-17 17:00 UTC
Fixed by http://selenic.com/repo/hg/rev/2371f4aea665
Matt Mackall <mpm@selenic.com>
merge: give a special message for internal:merge failure (issue3105)

(please test the fix)
Comment 6 Bugzilla 2012-05-12 09:25 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:25 EDT  ---

This bug was previously known as _bug_ 3105 at http://mercurial.selenic.com/bts/issue3105