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