On Sun, Feb 17, 2008 at 08:59:31AM +0100, Steffen Prohaska wrote: > > I am not upset at all and I really appreciate Charles work for > adding a generic mechanism. I was just wondering why not taking > the direct way of adding tools to git-mergetool one by one until > we eventually have a rather complete list of supported tools. > This would be the easiest solution for end users if their > preferred tool is supported. It is also easier to add support > for a specific tool than a generic mechanism. 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 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. 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 - 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
