Painful user experience with 'hg resolve'

[Brendan Cully]

On Thursday, 25 August 2011 at 18:01, timeless wrote:
> If 'hg resolve' stored the hash+date of the unresolved files it
> generated (I.e. After whatever merge tool it used did whatever it
> did), could it warn users when 'hg resolve' is run again and the
> hashes/dates don't match (I.e. After the user did further work)?

+1. I've wanted this for a long time. I believe it would stop a lot of
foot-shooting.

> On 8/25/11, Matt Mackall <mpm at selenic.com> wrote:
> > 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'.)
> >
> >
> >
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at selenic.com
> > http://selenic.com/mailman/listinfo/mercurial-devel
> >
>