Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Oct 10, 2007, 17:03 UTC
- Message-ID
- <Pine.LNX.4.64.0710101759080.4174@racer.site>
- In-Reply-To
- <FBE79360-4B3A-4C92-B8AA-76989D933009@zib.de>
Hi,
On Wed, 10 Oct 2007, Steffen Prohaska wrote:
Show 47 quoted lines
> 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