Painful user experience with 'hg resolve'

[timeless]

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)?

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'.)
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

-- 
Sent from my mobile device