On Sat, Feb 16, 2008 at 11:37:31PM +0100, Steffen Prohaska wrote: > > On Feb 16, 2008, at 7:53 PM, Charles Bailey wrote: > > >Currently git mergetool is restricted to a set of commands defined > >in the script. You can subvert the mergetool.<tool>.path to force > >git mergetool to use a different command, but if you have a command > >whose invocation syntax does not match one of the current tools then > >you would have to write a wrapper script for it. > > > >[...] > > > >This is a preliminary patch which aims to make it easier to use > >a.n.other 3-way merge tool with git-mergetool without either hacking > >the source or writing a wrapper script for the tool. > > Why not just add the tools you have in mind to git mergetool? If > everyone did that eventually we would have direct support for a > rather long list of tools. This would be the easiest solution > for the end user: He could just choose the preferred tool and use > it. The invocation of each merge tool would be coded in > mergetool. The exact command line could be fine tuned and would > be reviewed by other git developers. > I have to disagree with this approach. I didn't actually have these tools in mind when I wrote the patch, I searched around for tools that I've used in the past and tools that I know that other people use. I had in mine the questions that I'd want to be able to answer when people ask me about git. It's not that the list will be large, it's that it will never be complete because there will always be tools that aren't globally available. When I'm asked "can I use xyz visual merge tool" with git there will always be some xyz for which the tool isn't yet in the list. It's a lot more difficult to sell "patch the tool, submit the patch so it doesn't get lost in the next upgrade of git, oh and support the patch so that it does get integrated" than it is to sell "take the command line format, massage it and put it in your system/global config". > If you just integrated these tools directly I could use them > right away instead of first reading the documentation of the > custom mechanism and then looking up how to configure the right > command line for the tool I want to use. If the tools were > directly integrated I could for example just say "git mergetool > --tool=p4". > > That does not mean I am opposed to adding a mechanism for > handling custom tools. But easier for the end user would be > if the tools were directly integrated. > > Steffen Sure, it's nice when the tool you want is already integrated but the list is never going to be perfect. This patch was designed to support the fallback position: OK, my tool isn't natively supported, how easily can I get it working? I don't believe that git installs a system config by default, but one idea I had was to rip out all of the native tools support in git mergetool and replace it with a list of predefined custom tools configs. This would put all merge tools on an equal footing and should make extra tool support patches simpler and easier to integrate. This doesn't have any legs without a system default config, though. 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
