Painful user experience with 'hg resolve'

[Matt Mackall]

On Thu, 2011-08-25 at 16:33 -0400, Greg Ward wrote:
> Here's an interesting tale from the Real World. A developer just came
> to me asking how she could have possibly broken the build by
> committing merge conflicts, because she followed all the instructions
> to the letter. Here's what she did (translated from our workflow to
> more normal terminology):
> 
>   $ hg update default
>   $ hg merge --tool internal:merge <prev branch>
>   [...conflicts in Foo.java...]
> 
> "OK, let's resolve all conflicts"
> 
>   $ hg resolve --all
> 
> (This is actually pointless since she has internal:merge configured as
> her default merge tool. But it's harmless apart from wasting a few CPU
> cycles. And it can be useful for people who merge with internal:merge,
> but then resolve with (say) kdiff3. I tend to do that myself.)
> 
> "Now I fix my conflicts and make sure the code builds"
> 
>   $ vim Foo.java
>   $ make
> 
> "Great! Now I'll check what other files have conflicts"
> 
>   $ hg resolve --all    (**)
>   [...messages about Foo.java being merged again and failing again...]
> 
> "Good, it worked! Ready to commit!"
> 
>   $ hg resolve -m Foo.java
>   $ hg commit ...
> 
> You probably spotted the problem up there at (**): she wanted "hg
> resolve -l", but actually used "hg resolve --all".

Well, that is an issue, sure.

But I think the deeper issue is continuing to use stone-age SCM
technology with a tool that's designed around more modern tools.
Conflict markers date back at least to 1982 (RCS) if not 1972 (SCCS).
With an interactive merge tool, Mercurial KNOWS when something isn't
resolved because the tool tells it. With internal:merge, it has to trust
you know what you're doing when you say "resolve -m". We might be able
to put in a sanity check for conflict markers here.

Another way this bites people is when they manually fix up all their
conflict markers and then a subsequent "resolve -a" helpfully undoes all
their work because no one told Mercurial the file had finished being
resolved. Again: only happens if you do your merge by hand rather than
with a merge tool. Not sure if we can sanity-check this: common usage of
resolve is to completely restart a bungled merge and there's no good way
to distinguish a bungled merge from a good one.

Lastly, SVN refugees often think 'svn resolveD' (mark a file resolved
after fixing up RCS-style markers) and 'hg resolve' (attempt to resolve
merge conflicts interactively) so will attempt to do 'hg resolve foo' 
to mark a file resolved (because they're still merging by hand too!) and
their work will vanish.

(By the way, the similarity to SVN's command is pure coincidence: I
wasn't aware of it when I created 'hg resolve'.)

-- 
Mathematics is the supreme nostalgia of our time.