From: Charles Bailey Date: Mon, 18 Feb 2008 08:14:46 GMT Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time 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: > Theodore Tso 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.