Sebastian Schuberth <> writes:

> On Wed, Aug 8, 2012 at 11:26 PM, Junio C Hamano <> wrote:
>> I do not have a strong reason to vote for or against inclusion of
>> yet another tool as mergetool backends (read: Meh), but what this
> That sounds almost as if you'd like to keep the number of directly
> supported mergetools small (I'm not talking about about the length of
> the list of mergetools in the docs right now). I was always thinking,
> the more mergetools, the better. Do you think differently?

It depends on the pros-and-cons between the cost of forcing many
people to see a list of supported backends with yet one more item
(the list only grows and rarely shrinks) and the benefit of the
subset of users who can now use it.  I couldn't measure how widely
the particular commercial program is used from your proposed commit
log message, and that is where my "for or against" comes from.

>> patch does to Documentation/merge-config.txt is actively unwelcome.
>> As we discussed earlier in
>> the longer term direction is to reduce the names of tools listed
>> there.
>> I am somewhat saddened to find your name in that thread; you should
>> have been aware of that discussion when you wrote this patch.
> I still agree that not listing all mergetools in multiple places is a
> good thing. But doing the whole stuff of extending --tool-help for
> git-mergetool and git-difftool to return a simple list that can be
> used in git-completion.bash etc. IMHO is a separate topic and out of
> scope of this patch.

Exactly.  If you know that is the long term direction, I would have
preferred you _not_ to touch any existing descriptions of the tools
(not even changing them to refer to "--tool-help") in this patch, in
order to avoid unnecessary conflicts with the topic of unifying the
list of tool backends, which can be written and cooked separately.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to