All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert Estelle via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Robert Estelle <robertestelle@gmail.com>,
	Robert Estelle <robert.estelle@gmail.com>,
	Robert Estelle <robertestelle@gmail.com>
Subject: [PATCH v2] completion: fix incorrect bash/zsh string equality check
Date: Mon, 25 Oct 2021 22:29:33 +0000	[thread overview]
Message-ID: <pull.1096.v2.git.git.1635200973354.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.1096.git.git.1633642772432.gitgitgadget@gmail.com>

From: Robert Estelle <robertestelle@gmail.com>

In the basic `[`/`test` command, the string equality operator is a
single `=`. The `==` operator is only available in `[[`, which is a
bash-ism also supported by zsh.

This mix-up was causing the following completion error in zsh:
> __git_ls_files_helper:7: = not found

(That message refers to the extraneous symbol in `==` ← `=`).

This updates that comparison to use a single `=` inside the
basic `[ … ]` test conditional.

Although this fix is inconsistent with the other comparisons in this
file, which use `[[ … == … ]]`, and the two expressions are functionally
identical in this context, that approach was rejected due to a
preference for `[`.

Signed-off-by: Robert Estelle <robertestelle@gmail.com>
---
    completion: Fix incorrect bash/zsh string equality check
    
    v2: This updates the comparison to remove the extraneous = symbol in ==,
    and use the [ … ] conditional instead.
    
    v1: (rejected) updated that comparison to use the extended [[ … ]]
    conditional for consistency with the other checks in this file.
    
    This fixes an error in contrib/completion/git-completion.bash caused by
    the incorrect use of == (vs. single =) inside a basic [/test command.
    Double-equals == should only be used with the extended [[ comparison.
    
    This was causing the following completion error in zsh:
    
    > __git_ls_files_helper:7: = not found
    

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1096%2Frwe%2Ffix-completion-sh-eq-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1096/rwe/fix-completion-sh-eq-v2
Pull-Request: https://github.com/git/git/pull/1096

Range-diff vs v1:

 1:  6fd09347385 ! 1:  eee166c8c99 completion: fix incorrect bash/zsh string equality check
     @@ Commit message
      
          (That message refers to the extraneous symbol in `==` ← `=`).
      
     -    This updates that comparison to use the extended `[[ … ]]` conditional
     -    for consistency with the other checks in this file.
     +    This updates that comparison to use a single `=` inside the
     +    basic `[ … ]` test conditional.
     +
     +    Although this fix is inconsistent with the other comparisons in this
     +    file, which use `[[ … == … ]]`, and the two expressions are functionally
     +    identical in this context, that approach was rejected due to a
     +    preference for `[`.
      
          Signed-off-by: Robert Estelle <robertestelle@gmail.com>
      
     @@ contrib/completion/git-completion.bash: __gitcomp_file ()
       __git_ls_files_helper ()
       {
      -	if [ "$2" == "--committable" ]; then
     -+	if [[ "$2" == "--committable" ]]; then
     ++	if [ "$2" = "--committable" ]; then
       		__git -C "$1" -c core.quotePath=false diff-index \
       			--name-only --relative HEAD -- "${3//\\/\\\\}*"
       	else


 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4bdd27ddc87..8ca9b15f21d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -515,7 +515,7 @@ __gitcomp_file ()
 # argument, and using the options specified in the second argument.
 __git_ls_files_helper ()
 {
-	if [ "$2" == "--committable" ]; then
+	if [ "$2" = "--committable" ]; then
 		__git -C "$1" -c core.quotePath=false diff-index \
 			--name-only --relative HEAD -- "${3//\\/\\\\}*"
 	else

base-commit: 225bc32a989d7a22fa6addafd4ce7dcd04675dbf
-- 
gitgitgadget

  parent reply	other threads:[~2021-10-25 22:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 21:39 [PATCH] completion: fix incorrect bash/zsh string equality check Robert Estelle via GitGitGadget
2021-10-08 20:50 ` Junio C Hamano
2021-10-08 20:57   ` brian m. carlson
2021-10-08 22:17     ` Robert Estelle
2021-10-08 22:05   ` Robert Estelle
2021-10-08 22:16     ` Junio C Hamano
2021-10-08 22:26       ` Robert Estelle
2021-10-08 23:09         ` Junio C Hamano
2021-10-25 22:20           ` Robert Estelle
2021-10-25 22:29 ` Robert Estelle via GitGitGadget [this message]
2021-10-28 16:36   ` [PATCH v2] " 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=pull.1096.v2.git.git.1635200973354.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=robert.estelle@gmail.com \
    --cc=robertestelle@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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.