Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Wed, 10 Oct 2007, Steffen Prohaska wrote:

> On Oct 10, 2007, at 4:33 PM, Johannes Schindelin wrote:
> 
> > On Tue, 9 Oct 2007, Steffen Prohaska wrote:
> > 
> > > This commit adds a mechanism to provide absolute paths to the 
> > > external programs called by 'git mergetool'. A path can be specified 
> > > in the configuation variable mergetool.<tool>.path. The 
> > > configuration variable is similar to how we name branches and 
> > > remotes. It is extensible if we need to specify more details about a 
> > > tool.
> > 
> > Okay, let's step back a bit.
> > 
> > What does mergetool do?  It calls different merge helpers, each with its
> > own convention how to call it.  For example, tkdiff is called either as
> > 
> > 		tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
> > 
> > or as
> > 
> > 		tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
> > 
> > depending if there is a base or not.  Another example is gvimdiff:
> > 
> > 		gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
> > 
> > which seems not to care if there is a base.
> > 
> > Now, would it not be much better if we had a way to specify the tool 
> > and the convention indepentently?  Like
> > 
> > merge.tkdiff.path = C:\bla\blub\wish.exe C:\blub\bleh\tkdiff.tcl
> > merge.tkdiff.options = -o %p -- %l %r
> > merge.tkdiff.optionsWithBase = -a %b -o %p -- %l %r
> > 
> > and have defaults for the tools we have in git-mergetool.sh _already_?
> 
> If you provide a generic mechanism to call an external tool, there's no 
> need to name the tool. A single mechanism (let's call it external) would 
> be sufficient, like
> 
> mergetool.external.path = c:\any\path\merge.exe
> mergetool.external.arg2way = %l %r --merge2 --to=%p
> mergetool.external.arg3way = %b %l %r --merge3 --to=%p
> 
> But this places the burdon on the user to figure out the command line syntax
> and specify it correctly using git-config.

Guess why I did not want to  have a single mechanism.  I did _not_ propose 
to place the burden on the user to figure out the command line.

Besides, I do not want to do away with the automatic detection of the 
tool, which _implies_ having a list of defaults for the command line 
syntax, which in turn _commands_ having the name instead of "external".

While your solution is an obvious short term fix, I maintain that my 
proposal is the Right Thing in the long run.

Ciao,
Dscho