Re: [RFC PATCH 2/3] mergetools/kdiff3: allow opting-out of auto-merges

> On Thu, May 09, 2013 at 03:17:30PM -0700, David Aguilar wrote:
>> Generally, "mergetool.<tool>.cmd" is not general enough since we've
>> always special cased the base vs. no-base code paths and we run
>> different commands depending on whether a base is available.
>
> Then this is a deficiency of the ".cmd" mechanism which should provide
> an "if all else fails" way to do things, even if ugly. We could simply
> add a BASELESS variable to the eval environment of the custom command.
> (Do we always create an empty file for $BASE, now?)
>
>> We could drop --auto altogether, which maybe is a better course of
>> action since it makes the behavior predictable and un-surprising, but
>> I do not know if anyone has come to rely on kdiff3's "auto-merge"
>> feature (hence the extended Cc: list).
>
> I disagree, I think that a mergetool should be allowed to be as
> helpful as possible and if it can resolve the merge unaided then this
> is no bad thing. I've worked with a number of people who were very
> happy with the current kdiff3 behaviour. Nothing prevents you from
> verifying the merge and fixing it up if it wasn't done perfectly by
> the tool, although I haven't ever encountered this with git+kdiff3.