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