[PATCH 2 of 3] mergetools.hgrc: disable vimdiff as a valid proposal for default mergetools

[Pierre-Yves David]

On Tue, Aug 21, 2012 at 11:42:32AM +0200, Martin Geisler wrote:
> Pierre-Yves David <pierre-yves.david at logilab.fr> writes:
> 
> > On Thu, Aug 02, 2012 at 04:02:32PM +0200, Mads Kiilerich wrote:
> >> On 02/08/12 15:35, Pierre-Yves David wrote:
> >>
> >> internal:merge is a last resort. It is not in any way recommended or
> >> best practice. Some users might have gotten used to that mode of
> >> operation from CVS and prefer that. They are welcome. We should
> >> however not expose new and innocent users to that - just like we
> >> should avoid 'merge' and 'vimdiff'.
> >
> > Well,
> >
> > 1) Vimdiff or other non obvious tools should not be the default,
> > 2) People need a simple way to resolve merge conflict,
> > 3) Solution that allows the user to use its usual text editor are the
> > only viable default solution I see.
> 
> If there's no graphical display, then I think I agree with you. It's
> nice that Mercurial probes the system and finds a GUI merge tool, but
> it's not nice if it fires up vimdiff when I merge over a SSH connection.

Well I do not know how to use kdiff3 or meld and I expect other user to be very
confused about them the first time it show up. once you know how to use them.
they are powerful tool. Until then they are major trouble for newby.

New user are --really-- afraid of merge.

> >> And as mentioned above: There are different opinions on whether <<<
> >> === >>> markers are pretty ok. Not having the ancestor revision makes
> >> it harder than necessary to resolve correctly.
> >
> > I agree that the current internalmerge marker are suboptimal. But It
> > does not seems hard to improve it. I use a version that create:
> >
> >     <<< local
> >     This is the local version
> >     ==== base
> >     This is the common ancestor version
> >     ==== other
> >     This is the merge target version
> >     >>>
> 
> Personally, I find anything more than "local and other" markers very
> annoying when we talk about textual markers. If I get markers in my file
> I want to be able to look at each conflict and delete the version I
> don't like -- a binary choice. I find it too much if there are three
> regions and I have to compare A with B and A with C and delete
> everything but one region.

I usually find useful to be able to understand what changes were introduced in
local and which were introduced in other. That helps me to merge the change. I
rarely can just drop one of the version.

> 
> For graphical tools I'm of course okay with seeing the ancestor version
> too -- I feel it makes sense to present more information in a graphical
> tool where they three files can be aligned properly with each other.
> 
> > So I would propose a default merge tools that:
> >
> >     1) Warn about the merge-tools help topic
> >     2) also create nice a useful marker
> >     3) also create base, other and local files
> >
> > - A marker only version would be accessible using "internal:mergemarkers"
> > - A file only version would be would be accessible using "internal:mergefiles"
> 
> We have internal:dump which I think is very close to what you want from
> internal:mergefiles.

Good to know


-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120821/0975af50/attachment.pgp>