All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH try2 0/4] completion: bash: a bunch of fixes
Date: Wed, 23 Dec 2020 08:31:37 -0600	[thread overview]
Message-ID: <5fe354c91a6f7_198be208d8@natae.notmuch> (raw)
In-Reply-To: <20201223141950.GA23264@szeder.dev>

SZEDER Gábor wrote:
> On Wed, Dec 23, 2020 at 07:38:12AM -0600, Felipe Contreras wrote:

> > and in zsh, this:
> > 
> >   local sfx
> >   echo "'${sfx- }'"
> > 
> > Prints an empty string.
> > 
> > That's because in zsh "local sfx" is effectively "local sfx=''" which in
> > my opinion is a bug.
> 
> Bash versions up to 4.0-alpha suffered from this bug as well; I believe
> the relevant changelog entry for 4.0-beta is this:
> 
>   e.  Fixed a bug that caused local variables to be created with the empty
>       string for a value rather than no value.
> 
> So the default Bash version on macOS still has this bug, thus
> __gitcomp_nl_append() is invoked with an empty string sfx parameter
> instead of a space, causing the test failure.  I can reproduce the
> test failure on Linux using Bash v3.2 (and v3.1 and v3.0), and it
> passes with v4.0 and later versions.

Ahhh, interesting.

So I'm not the only one who considers it a bug.

> > I see 5 courses of action:
> > 
> >  1. Drop the offending patch: this is wrong because the bug is still
> >     there, we are just not checking for it.
> >  2. Add a BASH prereq just for that test, or test_expect_unstable (we
> >     would need to add extra code for both of those).
> >  3. Add the fix, but not the test for the fix.
> 
> I'm for this option 3: this patch does fix a bug for users of Bash
> v4.0 or later, while it doesn't change the behavior with v3.2 or
> earlier (and with zsh, if I understand correctly).  OTOH, the test
> doesn't seem to be all that useful: while it does demonstrate the
> issue, it checks only one of those callsites that passed the wrong
> suffix, and, more importantly, it doesn't protect us from adding
> another callsites with similarly wrong suffex in the future.

I'm fine with that option.

> In any case, the commit message should note that the fix doesn't work
> with all Bash versions and why.

Yes. I will send a re-roll (unless somebody objects beforehand).

-- 
Felipe Contreras

  reply	other threads:[~2020-12-23 14:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-19 14:06 [PATCH try2 0/4] completion: bash: a bunch of fixes Felipe Contreras
2020-12-19 14:06 ` [PATCH try2 1/4] completion: bash: fix prefix detection in branch.* Felipe Contreras
2020-12-19 14:06 ` [PATCH try2 2/4] completion: bash: add correct suffix in variables Felipe Contreras
2020-12-19 14:06 ` [PATCH try2 3/4] completion: bash: fix for suboptions with value Felipe Contreras
2020-12-19 14:06 ` [PATCH try2 4/4] completion: bash: fix for multiple dash commands Felipe Contreras
2020-12-23  9:14 ` [PATCH try2 0/4] completion: bash: a bunch of fixes Junio C Hamano
2020-12-23 13:38   ` Felipe Contreras
2020-12-23 14:19     ` SZEDER Gábor
2020-12-23 14:31       ` Felipe Contreras [this message]
2020-12-23 20:25       ` Junio C Hamano
2020-12-24  0:21         ` Felipe Contreras

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=5fe354c91a6f7_198be208d8@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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 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.