Painful user experience with 'hg resolve'

Martin Geisler mg at aragost.com
Fri Aug 26 02:34:28 CDT 2011


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.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list