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)
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.
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.
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)
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!
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)
--- 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