git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Reece Dunn <msclrhd@googlemail.com>
To: markus.heidelberg@web.de
Cc: Jay Soffian <jaysoffian@gmail.com>,
	Charles Bailey <charles@hashpling.org>,
	Scott Chacon <schacon@gmail.com>, git list <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	David Aguilar <davvid@gmail.com>
Subject: Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool  option
Date: Fri, 30 Oct 2009 11:25:25 +0000	[thread overview]
Message-ID: <3f4fd2640910300425q602471a6v1111a7dceee7746c@mail.gmail.com> (raw)
In-Reply-To: <200910301135.59831.markus.heidelberg@web.de>

2009/10/30 Markus Heidelberg <markus.heidelberg@web.de>:
> Jay Soffian, 30.10.2009:
>> On Thu, Oct 29, 2009 at 9:02 PM, Markus Heidelberg
>> <markus.heidelberg@web.de> wrote:
>> > He didn't mean p4merge on other platforms, but other merge tools on Mac
>> > OS X. What about all the other merge tools already in mergetool--lib?
>> > Should they get special handling, too?
>>
>> If someone wants to scratch that itch, then yes. The default diff tool
>> for OS X has its helper already in /usr/bin (opendiff). p4merge is
>> arguably a better merge tool, and it installs as an app bundle in
>> /Applications. I'm not sure about the other diff tools, I haven't
>> looked.
>>
>> > And for Windows we could add C:\Program Files\MergeToolX\tool.exe for
>> > every merge tool.
>>
>> If it makes those tools easier to use with git, and if someone on
>> Windows wants to scratch that itch, then yes, we should.
>
> Another possible problem: the user can change the installation
> destination on Windows. What's the behaviour of Mac OS here? Is the
> instalation path fixed or changeable?

For Windows, the program should have an InstallDir or similar registry
value in a fixed place in the registry to point to where it is
installed (something like
HKLM/Software/[Vendor]/[Application]/[Version]).

As for Linux, there is no guarantee that things like p4merge are in
the path either. It could be placed under /opt/perforce or
/home/perforce.

What would be sensible (for all platforms) is:
  1/  if [difftool|mergetool].toolname.path is set, use that (is this
documented?)
  2/  try looking for the tool in the system path
  3/  try some intelligent guessing
  4/  if none of these work, print out an error message -- ideally,
this should mention the configuration option in (1)

(3) is what is being discussed. It is good that it will work without
any user configuration (especially for standard tools installed in
standard places), but isn't really a big problem as long as the user
is prompted to configure the tool path. Also, I'm not sure how this
will work with multiple versions of the tools installed (e.g. vim/gvim
and p4merge).

- Reece

  reply	other threads:[~2009-10-30 11:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 22:36 [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option Scott Chacon
2009-10-27 23:00 ` Charles Bailey
2009-10-28  7:18   ` Junio C Hamano
2009-10-28  9:00   ` David Aguilar
2009-10-28 15:37     ` Scott Chacon
2009-10-28 21:39       ` Scott Chacon
2009-10-28 23:37         ` Junio C Hamano
2009-10-29  6:17           ` Jay Soffian
2009-10-29 22:12         ` Charles Bailey
2009-10-30  0:47           ` Jay Soffian
2009-10-30  1:02             ` Markus Heidelberg
2009-10-30  3:00               ` Jay Soffian
2009-10-30 10:35                 ` Markus Heidelberg
2009-10-30 11:25                   ` Reece Dunn [this message]
2009-10-30 15:17                     ` Jay Soffian
2009-10-30 15:30                       ` Markus Heidelberg
2009-10-30 17:44         ` Charles Bailey
2009-10-30 18:54           ` Junio C Hamano

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=3f4fd2640910300425q602471a6v1111a7dceee7746c@mail.gmail.com \
    --to=msclrhd@googlemail.com \
    --cc=charles@hashpling.org \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jaysoffian@gmail.com \
    --cc=markus.heidelberg@web.de \
    --cc=schacon@gmail.com \
    /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).