On Sun, Feb 17, 2008 at 04:30:43PM -0800, Junio C Hamano wrote: > Theodore Tso <tytso@xxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
