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 04:30:43PM -0800, Junio C Hamano wrote:
> Theodore Tso <tytso@MIT.EDU> writes:
> 
> > I have no objection to a generic mechanism, but I don't see the value
> > of Charles suggestion to rip out support for the existing tools
> > supported by git-mergetool.
> 
> I missed that suggestion but I agree removing existing support
> would not make much sense.

As I said in an earlier reply this was really more of a thought
exercise about my patch than a serious suggestion for integration.

> > 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.
> 
> Hmm, although I do not have strong opinions either way, I think
> the necessary interface is narrow enough that we could use
> environment variables here.  Charles's implementation does
> "eval" but it is easy to replace it to run the custom command
> after exporting the necessary variables, isn't it?

Do you mean instead of:

( eval $tool )

something like:
BASE="$BASE" LOCAL="$LOCAL" REMOTE="$REMOTE" MERGED="$MERGED" $tool

In this case we can skip the whole s/path/MERGED/ patch as it is
unnecessary, and should we now GIT_ prefix the variables as they will
intrude on the environment of the spawned command (not just a specific
sub-shell)? 

Let me know what you think and I can integrate it into my next patch
version.

Charles.