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

On Thu, May 9, 2013 at 10:41 PM, Charles Bailey [off-list ref] wrote:

On Thu, May 09, 2013 at 03:17:30PM -0700, David Aguilar wrote:

quoted

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?)

quoted

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.

That's the bit of info I was needing.

I can always tell the one person who ran into this that "that's how it
is" and explain why it's a good thing.

"one person" < "number of people" so it's an easy decision, and we
don't need to make the tool worse to cater to someone that's new to
git.

Thanks Charles,
--
David