git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Aguilar <davvid@gmail.com>
Cc: Sven Strickroth <sven.strickroth@tu-clausthal.de>,
	git@vger.kernel.org, Sebastian Schuberth <sschuberth@gmail.com>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH] mergetools: Add tortoisegitmerge helper
Date: Thu, 24 Jan 2013 23:21:21 -0800	[thread overview]
Message-ID: <7vvcal683y.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAJDDKr5O70tTfwuipWcYVJL6gM3bUyQh-22yVO89xn8OFsQOpw@mail.gmail.com> (David Aguilar's message of "Thu, 24 Jan 2013 22:11:45 -0800")

David Aguilar <davvid@gmail.com> writes:

> Even though the old tortoisemerge and the new tortoisegitmerge
> have completely different syntax, could we still use the existence
> of one when deciding which syntax to use?
> ...
> ...and then later merge_cmd and diff_cmd
> can delegate to {diff,merge}_cmd_legacy() and
> {diff,merge}_cmd_gitmerge() functions to do the work.
>
> It's just a thought.  translate_merge_tool_path()
> is too low-level to do it, but it seems like we could
> get away with it by having some extra smarts in the
> scriptlet.

Sounds like a far better approach to me.  I'd like to at least see
an attempt be made to make that work first.

>>>> This paragraph needs to be rewritten to unconfuse readers.  The
>>>> original is barely intelligible, and it becomes unreadable as the
>>>> set of tools subtracted by "minus" and added by "plus" grows.
>>>
>>> But I think this should not be part of this patch.
>>
>> I agree that it can be done (and it is better to be done) as a
>> preparatory step.  The current text is barely readable, but with
>> this patch there will be two "minus", and the result becomes
>> unreadable at that point.
>>
>> It also could be done as a follow-up documentation readability fix.
>
> Another thought would be to minimize this section as much
> as possible and point users to "git difftool --tool-help".

We had a similar discussion here:

  http://thread.gmane.org/gmane.comp.version-control.git/201913/focus=201976

and Documentation/git-{diff,merge}tool.txt have stayed quiet since
then.

But Documentation/merge-config.txt tries to list everything that _could_
be enabled, and I do not necessarily think having one single
location that lists everything is such a bad idea.

Is there a way for me to programatically tell what merge.tool and
diff.tool could be enabled for a particular source checkout of Git
regardless of what platform am I on (that is, even though I won't
touch Windows, I want to see 'tortoise' appear in the output of such
a procedure)?  We could generate a small text file from the Makefile
in Documentation and include it when building the manual pages if
such a procedure is available.

  reply	other threads:[~2013-01-25  7:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 11:27 [PATCH] mergetools: Add tortoisegitmerge helper Sven Strickroth
2013-01-21  0:43 ` Junio C Hamano
2013-01-21  8:24   ` Sven Strickroth
2013-01-21  8:26   ` Sven Strickroth
2013-01-24 11:19     ` Sven Strickroth
2013-01-24 19:51     ` Junio C Hamano
2013-01-24 22:07       ` Sven Strickroth
2013-01-24 22:15         ` Junio C Hamano
2013-01-25  6:11           ` David Aguilar
2013-01-25  7:21             ` Junio C Hamano [this message]
2013-01-25  7:54               ` David Aguilar
2013-01-25  9:48                 ` John Keeping
2013-01-25  9:06         ` [PATCH] mergetools: Enhance tortoisemerge to work with Sven Strickroth
2013-01-25 10:09           ` David Aguilar
2013-01-25 13:07             ` Sven Strickroth
2013-01-25 18:28               ` Junio C Hamano
2013-01-26  0:58                 ` Sven Strickroth
2013-01-26  1:14                 ` Sven Strickroth
2013-01-26  1:15                 ` [PATCH 1/2] mergetools: Added support for TortoiseGitMerge Sven Strickroth
2013-01-26  1:17                 ` [PATCH 2/2] mergetools: Make tortoisemerge work with Sven Strickroth
2013-01-26  7:10                   ` David Aguilar
2013-01-27  9:14                     ` Sven Strickroth
2013-01-27 17:48                       ` Junio C Hamano
2013-02-01 19:33                         ` [PATCH] mergetools: Enable tortoisemerge to handle filenames with Sven Strickroth
2013-02-01 20:07                           ` Sebastian Schuberth
2013-02-01 20:10                             ` Sven Strickroth
2013-02-01 20:15                             ` Junio C Hamano
2013-02-01 20:17                               ` Sven Strickroth
2013-02-01 20:16                             ` [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge Sven Strickroth
2013-02-02  1:59                               ` David Aguilar
2013-02-02  2:08                                 ` 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=7vvcal683y.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sschuberth@gmail.com \
    --cc=sven.strickroth@tu-clausthal.de \
    /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).