Painful user experience with 'hg resolve'
Matt Mackall
mpm at selenic.com
Fri Aug 26 12:16:51 CDT 2011
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.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list