possible completion bug with --set-upstream-to=

possible completion bug with --set-upstream-to=

[Ernesto Alfonso]

Whenever I type the last <TAB> to complete origin/master, as in below:

> git branch --set-upstream-to=orig<TAB>

what I get is:

> git branch origin/master

instead of the expected:

> git branch --set-upstream-to=origin/master

git version and OS:

>git version 2.1.4
>
>Distributor ID:	Debian
>Description:	Debian GNU/Linux 8.7 (jessie)
>Release:	8.7
>Codename:	jessie
>

Thanks,

Ernesto

Re: possible completion bug with --set-upstream-to=

[SZEDER Gábor]

> Whenever I type the last <TAB> to complete origin/master, as in below:
> 
> > git branch --set-upstream-to=orig<TAB>
> 
> what I get is:
> 
> > git branch origin/master

Yeah, this shouldn't happen. 

> instead of the expected:
> 
> > git branch --set-upstream-to=origin/master

And indeed this is the expected behavior.

> git version and OS:
> 
> >git version 2.1.4

I couldn't reproduce the wrong behavior you saw using v2.1.4 in a
regular setup.
 
However, I could reproduce it after I removed the '=' character from
the set of characters in $COMP_WORDBREAKS, but then all completions
after an '--option=' are affected, e.g. 'pulseaudio --daemonize=t<TAB>
becomes 'pulseaudio true', too.

Could you tell us the content of your $COMP_WORDBREAKS using the
output of the following command (to make the included space, tab and
newline visible):

  printf "$COMP_WORDBREAKS" |tr ' \t\n' STN ; echo

If it's indeed the case that $COMP_WORDBREAKS is missing the '=', then
you should add it back and check whether it fixed the issue.  If it
did fix it, then you should try to figure out how the '=' got removed
from there.  Perhaps you used a program that ships its own completion
script whose developers changed $COMP_WORDBREAKS to their liking, not
knowing about its effect on other completion scripts.


Gábor

Re: possible completion bug with --set-upstream-to=

[Jeff King]

On Sat, Dec 30, 2017 at 09:28:06AM +0100, SZEDER Gábor wrote:

> I couldn't reproduce the wrong behavior you saw using v2.1.4 in a
> regular setup.
>  
> However, I could reproduce it after I removed the '=' character from
> the set of characters in $COMP_WORDBREAKS, but then all completions
> after an '--option=' are affected, e.g. 'pulseaudio --daemonize=t<TAB>
> becomes 'pulseaudio true', too.

I can reproduce here on my Debian unstable system.

> Could you tell us the content of your $COMP_WORDBREAKS using the
> output of the following command (to make the included space, tab and
> newline visible):
> 
>   printf "$COMP_WORDBREAKS" |tr ' \t\n' STN ; echo
> 
> If it's indeed the case that $COMP_WORDBREAKS is missing the '=', then
> you should add it back and check whether it fixed the issue.  If it
> did fix it, then you should try to figure out how the '=' got removed
> from there.  Perhaps you used a program that ships its own completion
> script whose developers changed $COMP_WORDBREAKS to their liking, not
> knowing about its effect on other completion scripts.

Looks like the system npm completion is the culprit:

  $ grep COMP_WORDBREAKS /etc/bash_completion.d/*
  /etc/bash_completion.d/npm:COMP_WORDBREAKS=${COMP_WORDBREAKS/=/}
  /etc/bash_completion.d/npm:COMP_WORDBREAKS=${COMP_WORDBREAKS/@/}
  /etc/bash_completion.d/npm:export COMP_WORDBREAKS

  $ dpkg -S /etc/bash_completion.d/npm
  npm: /etc/bash_completion.d/npm

Looks like there's already a bug filed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711810

Sadly there's even a patch which was taken upstream, but the debian
packaged version of npm is just woefully out of date.

-Peff