Painful user experience with 'hg resolve'

Steve Borho steve at borho.org
Fri Aug 26 13:58:23 CDT 2011


On Fri, Aug 26, 2011 at 12:16 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Fri, 2011-08-26 at 09:34 +0200, Martin Geisler wrote:
>> Matt Mackall <mpm at selenic.com> writes:
>>
>> > 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.
>>
>> I know you think people should use merge tools and then all will be
>> well. But it's not realistic to always merge everything at once when you
>> do "hg merge". The one file at a time approach we have by firing up the
>> merge tool again and again is file for 3 files, but bad for 50+ files
>> where you want to merge certain files before you merge others.
>>
>> TortoiseHg now defaults to using intermal:merge when do you "hg merge"
>> and then lets you fix the merge at your own leisure afterwards. That
>> model makes a lot of sense to me.
>
> Are you telling me that TortoiseHG is sticking conflict markers in files
> by default now? If so, I frankly think that's tragic: it's always been
> my goal to avoid a user ever having to see those horrible things again.
>
> Using internal:fail would have deferred the file merges just as well.

internal:fail actually is the default behavior "out of the box", but
internal:merge can be made the default via a global setting (if you
trust simplemerge to do trivial merges).

-- 
Steve Borho


More information about the Mercurial-devel mailing list