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

From: Charles Bailey <[email-masked]>
Date: Sun, 17 Feb 2008 23:28:58 +0000

On Sun, Feb 17, 2008 at 04:49:42PM -0500, Theodore Tso wrote:
> I think it *would* be better to use %(foo) extrapolation that
> environment variables, so that it's not required for users to write
> shell scripts unless absolutely necessary.

I understand that %(foo) is neater, but this would make the shell
implementation significantly more complex, and also potentially less
flexible (e.g. if you needed to do the opendiff style |cat trick or
some similar shell trickery).

The reason that I first posted a patch for a different config variable
for baseless merges was because I was that a significant number of
merge tools have significantly different syntaxes for two and three
way merges and I thought that it might be easier for users to do
something like:

git config mergetool.mymerge.cmd 'mytool --3way "$BASE" "$LOCAL" \
"$REMOTE" "$MERGED"'

git config mergetool.mymerge.cmdNoBase 'mytool --2way "$LOCAL" \
"$REMOTE" "$MERGED"'

than it would be to do something like (totally untested):

git config mergetool.mymerge.cmd 'if test -f "$BASE"; then;\
 mytool --3way "$BASE" "$LOCAL" "$REMOTE" "$MERGED"; else; \
 mytool --2way "$LOCAL" "$REMOTE" "$MERGED"; fi'

So in the former case you are still using shell syntax, but a simple
subset of shell should suffice for most needs.  The later case
requires more wizardry.

> When we get around to rewriting git-mergetool in C, it might make
> sense to put the tool support in the various shell scripts that are
> installed in the git helper binary directory (i.e.,
> git-mergetool-kdiff3, git-mergetool-meld, etc.)  That would make it
> easier for users to create new shell scripts to support new tools if
> necessary.
> 
> 					- Ted

This makes sense to me, although I have to say that I'm not really
sure I see the value of turning git-mergetool into C.  It seems to
make a lot of sense as a shell helper, but is it a general principle
that all of git's commands should eventually be converted to C?

Charles.