On Oct 10, 2007, at 4:33 PM, Johannes Schindelin wrote:
Hi,
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. Things like proper
escaping may
be a hassel.
The solution I'm proposing is more user-friendly. Only the information
that is hard to figure out automatically and is easy to provide by the
user is asked for. The user only needs to tell the path to the
executable.
git-mergetool 'knows' about the correct command line syntax. There's
no need
to ask the user. The command line syntax is fixed and know. No option
here.
"git mergetool" could, for example, know that a certain tool just
doesn't
support 3-way.
And the code of git-mergetool is also quite easy. The only input
validation
that is needed is to check if mergetool.<tool>.path points to a valid
executable. If we provide a complex syntax for specifying command line
options we may have to do a lot more of input validation and processing.
I strongly favor my solution of including the command line syntax in
git-mergetool, and only ask the user for the path. I'm not against a
generic
mechanism to configure any tool. However, I do not plan to implement it.
If someone plans to develop a generic mechanism I see two options:
1) What's explained above.
2) _Define_ the parameters passed to the external command and ask the
user
to write a wrapper script to call his tool of choice. Similar to
what
GIT_EXTERNAL_DIFF does. Wrapper scripts would go to contrib/.
Both solutions would require more work from the user than needed.
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
