[PATCH 1 of 2] filemerge: add support for multiple merge tool versions (RFC)

[Mathias De Maré]

On Fri, Jan 8, 2016 at 3:11 PM, Yuya Nishihara <yuya at tcha.org> wrote:

> On Wed, 6 Jan 2016 07:57:16 +0100, Mathias De Maré wrote:
> > On Tue, Dec 22, 2015 at 8:06 PM, Matt Mackall <mpm at selenic.com> wrote:
> > > Another strategy would be to try running with the option and looking at
> > > output/exit codes.
> >
> > I looked into this and it seems it would add way too much complexity.
> > The main reason not to add '--auto-merge' (if I read it correctly in the
> > old threads) is concern about custom packages for CentOS 5 and 6
> breaking.
> > I could extend buildrpm (or dockerrpm) to create a file
> > /etc/mercurial/hgrc.d/mergetools.centos[5,6].rc containing only the old
> > arguments for Meld.
>
> It seems the loading order of *.rc files is unstable.
>
I originally figured this would not be a major problem, since the Mercurial
mergetools.rc is not put in /etc.
However, Tortoisehg does seem to use a mergetools.rc. Is there a reason for
this difference?

>
> > All other OSes would get the regular arguments (which
> > we can change to add '--auto-merge'). I believe this would be an easier
> > approach that does not introduce too much complexity.
> >
> > Does this seem like a good approach?
>
> Alternatively, you could add new key for meld with --auto-merge. For
> instance,
> we have "kdiff3" and "kdiff3-noauto" in default configuration of
> TortoiseHg.
>
Indeed, that's also an option (and perhaps even less work). It's a problem
with regards to backwards-compatibility though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160114/fd4c938b/attachment.html>