* Re: bug in bash completion for git-branch --set-upstream-to on OSX
@ 2015-03-22 11:06 SZEDER Gábor
2015-03-23 13:45 ` Jason Karns
0 siblings, 1 reply; 5+ messages in thread
From: SZEDER Gábor @ 2015-03-22 11:06 UTC (permalink / raw)
To: Jason Karns; +Cc: git
Hi,
Quoting Jason Karns <karns.17@gmail.com>:
> There appears to be a bug in the bash completion for git-branch when
> attempting to complete the remote ref argument for --set-upstream-to=
>
> When:
>
> $ git branch --set-upstream-to=origin/mast<TAB>
>
> I would expect it to complete to:
>
> $ git branch --set-upstream-to=origin/master
>
> However, the completion for --set-upstream-to= completes the ref
> correctly, but completely wipes the --set-upstream option; resulting
> in:
>
> $ git branch origin/master
Strange.
The code in question
case "$cur" in
--set-upstream-to=*)
__gitcomp "$(__git_refs)" "" "${cur##--set-upstream-to=}"
;;
looks unsuspicious, this is the "standard" way to complete
'--option=<TAB>' (except that we should use __gitcomp_nl() for
completing refs, but that should have no effect on this issue). Does
the same issue affect other 'git cmd --option=<TAB>' completions as
well, e.g. 'git log --date=<TAB>' or 'git commit --reuse-message=<TAB>'?
We had a similar issue with ':' on the command line a looong while
ago, see v1.5.6.4~9^2 (bash completion: Resolve git show ref:path<tab>
losing ref: portion, 2008-07-15). Maybe we are dealing with the same
issue here, just a different character?
What does
printf "$COMP_WORDBREAKS" |tr ' \t\n' STN
print out? Is the '=' missing, perhaps? If that's indeed the case,
does adding it back (COMP_WORDBREAKS="$COMP_WORDBREAKS"=) fix the issue?
Gábor
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug in bash completion for git-branch --set-upstream-to on OSX
2015-03-22 11:06 bug in bash completion for git-branch --set-upstream-to on OSX SZEDER Gábor
@ 2015-03-23 13:45 ` Jason Karns
2015-03-23 14:42 ` Jason Karns
0 siblings, 1 reply; 5+ messages in thread
From: Jason Karns @ 2015-03-23 13:45 UTC (permalink / raw)
Cc: git
On Sun, Mar 22, 2015 at 7:06 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>
> Hi,
>
> Quoting Jason Karns <karns.17@gmail.com>:
>
>> There appears to be a bug in the bash completion for git-branch when
>> attempting to complete the remote ref argument for --set-upstream-to=
>>
>> When:
>>
>> $ git branch --set-upstream-to=origin/mast<TAB>
>>
>> I would expect it to complete to:
>>
>> $ git branch --set-upstream-to=origin/master
>>
>> However, the completion for --set-upstream-to= completes the ref
>> correctly, but completely wipes the --set-upstream option; resulting
>> in:
>>
>> $ git branch origin/master
>
>
> Strange.
>
> The code in question
>
> case "$cur" in
> --set-upstream-to=*)
> __gitcomp "$(__git_refs)" "" "${cur##--set-upstream-to=}"
> ;;
>
> looks unsuspicious, this is the "standard" way to complete
> '--option=<TAB>' (except that we should use __gitcomp_nl() for completing
> refs, but that should have no effect on this issue). Does the same issue
> affect other 'git cmd --option=<TAB>' completions as well, e.g. 'git log
> --date=<TAB>' or 'git commit --reuse-message=<TAB>'?
Yep, same buggy behavior.
>
> We had a similar issue with ':' on the command line a looong while
> ago, see v1.5.6.4~9^2 (bash completion: Resolve git show ref:path<tab>
> losing ref: portion, 2008-07-15). Maybe we are dealing with the same issue
> here, just a different character?
>
> What does
>
> printf "$COMP_WORDBREAKS" |tr ' \t\n' STN
>
> print out? Is the '=' missing, perhaps? If that's indeed the case,
> does adding it back (COMP_WORDBREAKS="$COMP_WORDBREAKS"=) fix the issue?
Adding it back in did indeed fix the issue. Now I get to track down
who/why `=` isn't present in COMP_WORDBREAKS.
Thanks!
>
> Gábor
>
Jason
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug in bash completion for git-branch --set-upstream-to on OSX
2015-03-23 13:45 ` Jason Karns
@ 2015-03-23 14:42 ` Jason Karns
0 siblings, 0 replies; 5+ messages in thread
From: Jason Karns @ 2015-03-23 14:42 UTC (permalink / raw)
To: Jason Karns; +Cc: git
For those curious, the source of the broken behavior is npm's
completion script. It is modifying COMP_WORDBREAKS. There are two open
issues against npm for this bug.
https://github.com/npm/npm/issues/4530
https://github.com/npm/npm/issues/5820
Jason
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug in bash completion for git-branch --set-upstream-to on OSX
2015-03-20 15:15 Jason Karns
@ 2015-03-22 3:24 ` Eric Sunshine
0 siblings, 0 replies; 5+ messages in thread
From: Eric Sunshine @ 2015-03-22 3:24 UTC (permalink / raw)
To: Jason Karns; +Cc: Git List
On Fri, Mar 20, 2015 at 11:15 AM, Jason Karns <karns.17@gmail.com> wrote:
> There appears to be a bug in the bash completion for git-branch when
> attempting to complete the remote ref argument for --set-upstream-to=
>
> When:
>
> $ git branch --set-upstream-to=origin/mast<TAB>
>
> I would expect it to complete to:
>
> $ git branch --set-upstream-to=origin/master
>
> However, the completion for --set-upstream-to= completes the ref
> correctly, but completely wipes the --set-upstream option; resulting
> in:
>
> $ git branch origin/master
>
> I'm running on OS X 10.9.5 with git from homebrew:
> $ bash --version
> GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin13.4.0)
Presumably, your bash is also from homebrew? Stock OS X bash tends to
be quite a bit older.
> $ git --version
> git version 2.3.3
I'm unable to reproduce this problem using git 2.3.3 and bash 4.3.33.
> The same behavior does *not* manifest (it works as expected) on CentOS
> 6.5, bash 4.1.2.1 (GNU bash, version 4.1.2(1)-release
> (x86_64-redhat-linux-gnu)). I'm running git 2.0.3 on CentOs but
> sourcing the shell completion script from latest source: 9ab698f
>
> I also cloned down latest git source on OS X and the bug still
> manifests when sourcing the completion script at 9ab698f.
Perhaps something in your bash startup script(s) is causing a strange
interaction.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug in bash completion for git-branch --set-upstream-to on OSX
@ 2015-03-20 15:15 Jason Karns
2015-03-22 3:24 ` Eric Sunshine
0 siblings, 1 reply; 5+ messages in thread
From: Jason Karns @ 2015-03-20 15:15 UTC (permalink / raw)
To: git
There appears to be a bug in the bash completion for git-branch when
attempting to complete the remote ref argument for --set-upstream-to=
When:
$ git branch --set-upstream-to=origin/mast<TAB>
I would expect it to complete to:
$ git branch --set-upstream-to=origin/master
However, the completion for --set-upstream-to= completes the ref
correctly, but completely wipes the --set-upstream option; resulting
in:
$ git branch origin/master
I'm running on OS X 10.9.5 with git from homebrew:
$ bash --version
GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin13.4.0)
$ git --version
git version 2.3.3
The same behavior does *not* manifest (it works as expected) on CentOS
6.5, bash 4.1.2.1 (GNU bash, version 4.1.2(1)-release
(x86_64-redhat-linux-gnu)). I'm running git 2.0.3 on CentOs but
sourcing the shell completion script from latest source: 9ab698f
I also cloned down latest git source on OS X and the bug still
manifests when sourcing the completion script at 9ab698f.
~ Jason
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-03-23 14:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-22 11:06 bug in bash completion for git-branch --set-upstream-to on OSX SZEDER Gábor
2015-03-23 13:45 ` Jason Karns
2015-03-23 14:42 ` Jason Karns
-- strict thread matches above, loose matches on Subject: below --
2015-03-20 15:15 Jason Karns
2015-03-22 3:24 ` Eric Sunshine
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.