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

From: Charles Bailey <charles@hashpling.org>
Date: Feb 18, 2008, 08:14 UTC
Message-ID: <20080218081446.GB12008@hashpling.org>
In-Reply-To: <7vir0nxg0c.fsf@gitster.siamese.dyndns.org>

On Sun, Feb 17, 2008 at 04:30:43PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> 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.

Show 9 quoted lines

> > 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.