Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time

[Charles Bailey <charles@hashpling.org>]

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.