git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: "Johannes Sixt" <j6t@kdbg.org>,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	pudinha <rogi@skylittlesystem.org>, "René Scharfe" <l.s.r@web.de>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Philippe Blain" <levraiphilippeblain@gmail.com>,
	"Philippe Blain" <levraiphilippeblain@gmail.com>,
	"Philippe Blain" <levraiphilippeblain@gmail.com>
Subject: [PATCH v3] mergetool--lib: fix '--tool-help' to correctly show available tools
Date: Thu, 07 Jan 2021 01:09:05 +0000	[thread overview]
Message-ID: <pull.825.v3.git.1609981745668.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.825.v2.git.1609184505071.gitgitgadget@gmail.com>

From: Philippe Blain <levraiphilippeblain@gmail.com>

Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool
variants, 2020-07-29) introduced a regression in the output of `git mergetool
--tool-help` and `git difftool --tool-help` [1].

In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the
supported mergetools and their variants and accumulate them in the variable
'variants', separating them with a literal '\n'.

The code then uses 'echo $variants' to turn these '\n' into newlines, but this
behaviour is not portable, it just happens to work in some shells, like
dash(1)'s 'echo' builtin.

For shells in which 'echo' does not turn '\n' into newlines, the end
result is that the only tools that are shown are the existing variants
(except the last variant alphabetically), since the variants are
separated by actual newlines in '$variants' because of the several
'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants.

Fix this bug by embedding an actual line feed into `variants` in
show_tool_names(). While at it, replace `sort | uniq` by `sort -u`.

To prevent future regressions, add a simple test that checks that a few
known tools are correctly shown (let's avoid counting the total number
of tools to lessen the maintenance burden when new tools are added or if
'--tool-help' learns additional logic, like hiding tools depending on
the current platform).

[1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/

Reported-by: Philippe Blain <levraiphilippeblain@gmail.com>
Based-on-patch-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
    Fix regression in 'git {diff,merge}tool --tool-help'
    
    Changes since v1:
    
     * Changed commit authorship (v1 sent with wrong identity).
    
    v1: I went with Johannes' suggestion finally because upon further
    inspection, René's patch for some reason (I did not debug further)
    caused to code to never reach 'any_shown=yes' in show_tool_help,
    therefore changing the output of the command.
    
    I guess it's too late for inclusion in 2.30...

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-825%2Fphil-blain%2Fmergetool-tool-help-fix-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-825/phil-blain/mergetool-tool-help-fix-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/825

Range-diff vs v2:

 1:  2b9dce31fd0 ! 1:  f66421939ec mergetool--lib: fix '--tool-help' to correctly show available tools
     @@ Commit message
          behaviour is not portable, it just happens to work in some shells, like
          dash(1)'s 'echo' builtin.
      
     -    For shells in which 'echo' does not turn '\n' into newlines, the end result is
     -    that the only tools that are shown are those that are found and have variants,
     -    since the variants are separated by actual newlines in '$variants' because of
     -    the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants.
     +    For shells in which 'echo' does not turn '\n' into newlines, the end
     +    result is that the only tools that are shown are the existing variants
     +    (except the last variant alphabetically), since the variants are
     +    separated by actual newlines in '$variants' because of the several
     +    'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants.
      
          Fix this bug by embedding an actual line feed into `variants` in
          show_tool_names(). While at it, replace `sort | uniq` by `sort -u`.
      
     -    To prevent future regressions, add a simple test that counts the number
     -    of tools shown by 'git mergetool --tool-help', irrespective of their
     -    installed status, by making use of the fact that mergetools are listed
     -    by 'git mergetool --tool-help' on lines starting with tabs. Prefix the
     -    `git config` commands used at the beginning of the test to remove the
     -    fake tools used by the previous test with 'test_might_fail' so that the
     -    test can be run independantly of the previous test without failing.
     +    To prevent future regressions, add a simple test that checks that a few
     +    known tools are correctly shown (let's avoid counting the total number
     +    of tools to lessen the maintenance burden when new tools are added or if
     +    '--tool-help' learns additional logic, like hiding tools depending on
     +    the current platform).
      
          [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/
      
     @@ t/t7610-mergetool.sh: test_expect_success 'mergetool -Oorder-file is honored' '
       	test_cmp expect actual
       '
       
     -+test_expect_success 'mergetool --tool-help shows all recognized tools' '
     -+	# Remove fake tools added in previous tests
     -+	test_might_fail git config --unset merge.tool &&
     -+	test_might_fail git config --remove-section mergetool.mytool &&
     -+	test_might_fail git config --remove-section mergetool.mybase &&
     -+	git mergetool --tool-help >output &&
     -+	grep "$(printf "\t")" output >mergetools &&
     -+	test_line_count = 30 mergetools
     ++test_expect_success 'mergetool --tool-help shows recognized tools' '
     ++	# Check a few known tools are correctly shown
     ++	git mergetool --tool-help >mergetools &&
     ++	grep vimdiff mergetools &&
     ++	grep vimdiff3 mergetools &&
     ++	grep gvimdiff2 mergetools &&
     ++	grep araxis mergetools &&
     ++	grep xxdiff mergetools &&
     ++	grep meld mergetools
      +'
      +
       test_done


 git-mergetool--lib.sh |  6 ++++--
 t/t7610-mergetool.sh  | 11 +++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 7225abd8112..78f3647ed97 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -46,9 +46,11 @@ show_tool_names () {
 		while read scriptname
 		do
 			setup_tool "$scriptname" 2>/dev/null
-			variants="$variants$(list_tool_variants)\n"
+			# We need an actual line feed here
+			variants="$variants
+$(list_tool_variants)"
 		done
-		variants="$(echo "$variants" | sort | uniq)"
+		variants="$(echo "$variants" | sort -u)"
 
 		for toolname in $variants
 		do
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 70afdd06fa7..6ac75b5d4c0 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -828,4 +828,15 @@ test_expect_success 'mergetool -Oorder-file is honored' '
 	test_cmp expect actual
 '
 
+test_expect_success 'mergetool --tool-help shows recognized tools' '
+	# Check a few known tools are correctly shown
+	git mergetool --tool-help >mergetools &&
+	grep vimdiff mergetools &&
+	grep vimdiff3 mergetools &&
+	grep gvimdiff2 mergetools &&
+	grep araxis mergetools &&
+	grep xxdiff mergetools &&
+	grep meld mergetools
+'
+
 test_done

base-commit: 4a0de43f4923993377dbbc42cfc0a1054b6c5ccf
-- 
gitgitgadget

  parent reply	other threads:[~2021-01-07  1:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-28 18:22 [PATCH] mergetool--lib: fix '--tool-help' to correctly show available tools Philippe Blain via GitGitGadget
2020-12-28 19:41 ` [PATCH v2] " Philippe Blain via GitGitGadget
2021-01-06 13:16   ` SZEDER Gábor
2021-01-06 13:34     ` Philippe Blain
2021-01-06 21:15     ` Junio C Hamano
2021-01-06 22:59       ` Philippe Blain
2021-01-06 23:06         ` Junio C Hamano
2021-01-07  0:32           ` Philippe Blain
2021-01-07  1:09   ` Philippe Blain via GitGitGadget [this message]
2021-01-07 13:37     ` [PATCH v3] " Philippe Blain

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=pull.825.v3.git.1609981745668.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=l.s.r@web.de \
    --cc=levraiphilippeblain@gmail.com \
    --cc=rogi@skylittlesystem.org \
    --cc=szeder.dev@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).