From: Charles Bailey Date: Sun, 17 Feb 2008 10:15:38 GMT Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time Message-ID: <20080217101538.GA21823@hashpling.org> In-Reply-To: On Sun, Feb 17, 2008 at 08:59:31AM +0100, Steffen Prohaska wrote: > 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. I just wanted to say that in my patch, as the configuration is a sub-shell, that it is perfectly possible to do this in a custom mergetool as well. I have different reasons for not liking a default system config file, namely the whole customize vs. updgrade conflict issues. An alternative that I have considered is to include a $(sharedir)/gitcore/mergetools.gitconfig which could contain the default native mergetool configs (both the commands and the 'trustExitCode' settings. Submitting a new merge tool patch becomes a simple matter of: "I've used and tested this in my system (or global) gitconfig, please add to the git distribution mergetool.gitconfig." I know that most git developers are just as at ease (if not more so) editing a git shell script as they are at using git config but I still believe that there is a significant group of users and potential users for whom there is an import barrier between configuring software and 'having' to hack it to get it to work. Charles.