On Oct 10, 2007, at 7:03 PM, Johannes Schindelin wrote:
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.
I did not intend to replace everything with an external mechanism.
What I
wanted to say is the following: If you add a generic mechanism in
addition
to the known tools it is sufficient to add a single generic mechanism
called 'external'. You could then choose from the list of known tools or
you could choose 'external' and provide everything needed as described
above.
Steffen
-
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
