All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: David Aguilar <davvid@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 7/7] mergetool--lib: Improve show_tool_help() output
Date: Fri, 25 Jan 2013 19:54:46 +0000	[thread overview]
Message-ID: <20130125195446.GA7498@serenity.lan> (raw)
In-Reply-To: <1359107034-14606-8-git-send-email-davvid@gmail.com>

On Fri, Jan 25, 2013 at 01:43:54AM -0800, David Aguilar wrote:
> Check the can_diff and can_merge functions before deciding whether to
> add the tool to the available/unavailable lists.  This makes --tool-help context-
> sensitive so that "git mergetool --tool-help" displays merge tools only
> and "git difftool --tool-help" displays diff tools only.

This log message is misleading - the existing code in
list_merge_tool_candidates already filters the tools like this, so the
change is more:

    mergetool--lib: don't use a hardcoded list for "--tool-help"

    Instead of using a list of tools in list_merge_tool_candidates, list
    the available scriptlets and query each of those to know whether it
    applies to diff mode and/or merge mode.

    guess_merge_tool still relies on list_merge_tool_candidates so we
    can't remove that function now.


The patch seems to do the right thing, although I have a couple of minor
nits...

> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
>  git-mergetool--lib.sh | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index db8218a..c547c59 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -168,17 +168,33 @@ list_merge_tool_candidates () {
>  }
>  
>  show_tool_help () {
> -	list_merge_tool_candidates
>  	unavailable= available= LF='
>  '
> -	for i in $tools
> +
> +	scriptlets="$(git --exec-path)"/mergetools
> +	for i in "$scriptlets"/*
>  	do
> -		merge_tool_path=$(translate_merge_tool_path "$i")
> +		. "$scriptlets"/defaults
> +		. "$i"
> +
> +		tool="$(basename "$i")"

Quotes are unnecessary here.

> +		if test "$tool" = "defaults"
> +		then
> +			continue
> +		elif merge_mode && ! can_merge
> +		then
> +			continue
> +		elif diff_mode && ! can_diff
> +		then
> +			continue
> +		fi

Would this be better as:

    test "$tool" = "defaults" && continue

    can_merge || ! merge_mode || continue
    can_diff || ! diff_mode || continue

or is that a bit too concise?

I'd prefer to see two separate if statements either way since the "test
$tool = defaults" case is different from the "does it apply to the
current mode?" case.  The "$tool = defaults" case could even move to the
top of the loop.

> +		merge_tool_path=$(translate_merge_tool_path "$tool")
>  		if type "$merge_tool_path" >/dev/null 2>&1
>  		then
> -			available="$available$i$LF"
> +			available="$available$tool$LF"
>  		else
> -			unavailable="$unavailable$i$LF"
> +			unavailable="$unavailable$tool$LF"
>  		fi
>  	done

  reply	other threads:[~2013-01-25 19:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25  9:43 [PATCH 0/7] mergetool-lib improvements for --tool-help David Aguilar
2013-01-25  9:43 ` [PATCH 1/7] git-mergetool: move show_tool_help to mergetool--lib David Aguilar
2013-01-25  9:43 ` [PATCH 2/7] git-mergetool: remove redundant assignment David Aguilar
2013-01-25  9:43 ` [PATCH 3/7] git-mergetool: don't hardcode 'mergetool' in show_tool_help David Aguilar
2013-01-25  9:43 ` [PATCH 4/7] git-difftool: use git-mergetool--lib for "--tool-help" David Aguilar
2013-01-25  9:43 ` [PATCH 5/7] mergetools/vim: Remove redundant diff command David Aguilar
2013-01-25  9:43 ` [PATCH 6/7] mergetools: Fix difftool/mergetool --tool-help listing for vim David Aguilar
2013-01-25 10:23   ` Sebastian Schuberth
2013-01-25 10:28     ` David Aguilar
2013-01-25 10:34       ` Sebastian Schuberth
2013-01-25 11:39         ` Sebastian Schuberth
2013-01-25 10:38   ` John Keeping
2013-01-25 10:40     ` David Aguilar
2013-01-25 19:11       ` Junio C Hamano
2013-01-25  9:43 ` [PATCH 7/7] mergetool--lib: Improve show_tool_help() output David Aguilar
2013-01-25 19:54   ` John Keeping [this message]
2013-01-25 20:06     ` Junio C Hamano
2013-01-25 20:08     ` John Keeping
2013-01-25 20:16       ` Junio C Hamano
2013-01-25 20:46         ` John Keeping
2013-01-25 20:56           ` Junio C Hamano
2013-01-25 21:16             ` John Keeping
2013-01-25 21:47               ` Junio C Hamano
2013-01-25 22:02                 ` John Keeping
2013-01-25 22:03                   ` [PATCH 8/7] mergetool--lib: don't call "exit" in setup_tool John Keeping
2013-01-26  0:24                     ` Junio C Hamano
2013-01-26  7:01                       ` David Aguilar
2013-01-26 12:17                       ` [PATCH 1/2 v2] " John Keeping
2013-01-26 13:50                         ` [PATCH 1/2 v3] " John Keeping
2013-01-25 22:04                   ` [PATCH 9/7] mergetool--lib: fix path lookup in guess_merge_tool John Keeping

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=20130125195446.GA7498@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.