On Feb 17, 2008, at 2:15 AM, Junio C Hamano wrote:
Charles Bailey <charles@xxxxxxxxxxxxx> writes:
On Sun, Feb 17, 2008 at 12:46:15AM +0000, Johannes Schindelin wrote:
So you'd rather have the end users do the same work for the same
tool over
and over again?
I'm sorry, I should have made myself clearer. I disagree that the
approach of adding new tool support to the source code as and when
they
are encountered is optimal. I believe that it is preferable to have a
solution that allows users to configure, rather then code, support
for
their own tools that do not to have native support.
I do not disagree that there is benefit to having a wide range of
tools that are supported natively.
I thought I made a reasonable argument for this in the rest of my
email that you took the headline from, but evidently I came across as
muddled.
I do not understand why people are so upset about this. I think
the approach Charles's patch takes is reasonable, with example
configurations to coax a few of his tools to be driven by
mergetool as backends, that demonstrate the customizing
framework works well.
I am not upset at all and I really appreciate Charles work for
adding a generic mechanism. I was just wondering why not taking
the direct way of adding tools to git-mergetool one by one until
we eventually have a rather complete list of supported tools.
This would be the easiest solution for end users if their
preferred tool is supported. It is also easier to add support
for a specific tool than a generic mechanism.
Maybe it is sufficient to refactor "git mergetool" to make it
really easy to add another tool. Our users are developers who
should know how to add a new tool directly to git mergetool if
they find some guidance in the source.
I see two benefits of the direct approach
- the source code of git mergetool could be kept simpler without
a generic configuration mechanism for unknown tools.
- users would be forced to integrate their tool into git mergetool
and hopefully they would send patches and eventually we'd have
rather complete arge number of tools supported.
(I know at least one case where this pressure helps and I expect
to see patches that we would not see if a generic mechanism
was available.)
It of course would also be good to throw in the native support
for the tools he used as examples but I'd say that they are
topics of separate patches.
I believe this is more important than a generic mechanism.
However, I am not opposed to a generic mechanism, ...
On Feb 17, 2008, at 1:20 AM, Charles Bailey wrote:
I don't believe that git installs a system config by default, but one
idea I had was to rip out all of the native tools support in git
mergetool and replace it with a list of predefined custom tools
configs. This would put all merge tools on an equal footing and
should
make extra tool support patches simpler and easier to integrate. This
doesn't have any legs without a system default config, though.
... but I am slightly opposed to this idea. Note that at least
in one case there is a trick needed to launch the tool. Such a
trick can easily be coded if the tool is directly added in
"git mergetool"; but it would be much harder to capture by a
generic mechanism via config variables. The example I mean is
opendiff that needs to be piped to cat (opendiff ... | cat).
Otherwise opendiff detaches FileMerge and returns immediately
without waiting for the user to complete the merge.
Steffen
-
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
