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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html