On Thu, May 9, 2013 at 10:41 PM, Charles Bailey <char...@hashpling.org> wrote: > 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.
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 -- 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
