From: Steffen Prohaska <prohaska@zib.de>
To: Theodore Tso <tytso@mit.edu>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
Date: Tue, 9 Oct 2007 08:30:39 +0200 [thread overview]
Message-ID: <C52FC9BE-13EE-4CB7-A5E9-164A2AC0E2E7@zib.de> (raw)
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Oct 8, 2007, at 11:57 PM, Theodore Tso wrote:
> On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> commands called by 'git mergetool'. A path can be specified
>> in the configuation variable merge.<toolname>path.
>
> This patch doesn't work if the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
>
> for i in $merge_tool_candidates; do
> if test $i = emerge ; then
> cmd=emacs
> else
> cmd=$i
> fi
> if type $cmd > /dev/null 2>&1; then
> merge_tool=$i
> break
> fi
> done
>
> is only checking to see if $cmd is in the path; it's not looking up
> the merge.<toolname>path variable in this loop.
I didn't change the automatic detection. It should work as before.
That is it continues to assume that merge tools are in PATH.
Is you expectation that git-mergetool should also consider the
absolute paths provided in merge.<toolname>path?
When I wrote the patch I had in mind that people will set the
merge.tool explicitly if they provide an absolute path. Automatic
detection would only be used if nothing is configured. In this
case a tool must be in PATH or would not be found.
> I guess the other question is whether we would be better off simply
> telling the user to specify an absolute pathname in merge.tool, and
> then having git-mergetool strip off the directory path via basename,
> and then on window systems, stripping off the .EXE or .COM suffix, and
> then downcasing the name so that something like "C:\Program
> Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
> right in guessing that the reason why you used merge.<toolname>path
> approach was to avoid this messy headache?
Yes. The program to start ECMerge on Windows is called 'guimerge.exe'.
Hard to derive a sensible short name from this.
So I don't think that an automatic translation is an option. I prefer
to provide the absolute paths.
Absolute paths have another advantage. You can set several of them
and choose a tool on the command line. Maybe you have several tools
you want to try. Or you hacking with someone else who preferes a
different tool. Or you just want to give a demo. I see
merge.<toolname>path more as a database associating absolute paths
with the shortnames.
My mental model is as follows:
1) merge.tool selects the mechanism needed to call the tool, that is
command line arguments, how merge result is passed, ...
2) merge.<toolname>path provides additional information how to locate
the selected tool in the filesystem.
The two points are somewhat orthogonal. I'd not fuse them into one.
Steffen
next prev parent reply other threads:[~2007-10-09 6:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-08 21:22 [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path Steffen Prohaska
2007-10-08 21:22 ` [PATCH] mergetool: add support for ECMerge Steffen Prohaska
2007-10-08 21:44 ` Theodore Tso
2007-10-09 6:14 ` Steffen Prohaska
2007-10-09 12:37 ` Johannes Schindelin
2007-10-09 12:49 ` Steffen Prohaska
2007-10-09 13:03 ` Alan Hadsell
2007-10-09 13:17 ` Steffen Prohaska
2007-10-09 14:21 ` Alan Hadsell
2007-10-08 21:57 ` [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path Theodore Tso
2007-10-08 22:01 ` Theodore Tso
2007-10-09 6:30 ` Steffen Prohaska [this message]
2007-10-08 22:00 ` Frank Lichtenheld
2007-10-09 6:42 ` Steffen Prohaska
2007-10-09 12:35 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C52FC9BE-13EE-4CB7-A5E9-164A2AC0E2E7@zib.de \
--to=prohaska@zib.de \
--cc=git@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).