From: Steffen Prohaska Date: Sun, 17 Feb 2008 07:59:31 GMT Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time Message-ID: In-Reply-To: <7vbq6g758h.fsf@gitster.siamese.dyndns.org> On Feb 17, 2008, at 2:15 AM, Junio C Hamano wrote: > Charles Bailey 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