Autocompletion - commands no longer work as stand alone

> I have for a number of years had the following in my .bashrc
>
> alias br="git branch"
> complete -F _git_branch br
>
> As well as similar commands for co and log.
>
> Recently though this broke, now when I type something like "br
> mas<command completion>" it will occasionally complain with messages
> like:
> bash: [: 1: unary operator expected
>
> From digging through the source it looks like this was broken back in
> April. (The commit is show at the bottom of this email.)
>
> So my questions are:
> 1. Is it reasonable for things like _git_branch to work as a
> standalone autocompletion function instead of having to go through
> _git? I certainly like it to work as a standalone function. I also use
> it to add autocompletion to other bash scripts that I use frequently.
>
> 2. If I add code that verifies that the variable cword exists at the
> start of these functions and only if not call something like
> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
> reasonable? I think this should address the performance concerns that
> caused these to be removed in the first place, but it may make the
> code uglier.
>
> I have already added wrapper functions in my bashrc so that this is no
> longer a problem for me, but there may be other people who start
> hitting this as well once they start using newer versions of git.
>
> Nathan
>
>
> commit da4902a73017ad82b9926d03101ec69a2802d1e7
> Author: SZEDER Gábor <szeder@ira.uka.de>
> Date:   Thu Apr 28 18:01:52 2011 +0200
>
>    completion: remove unnecessary _get_comp_words_by_ref() invocations
>
>    In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
>    with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
>    to access completion-related variables.  That was large change, and to
>    make it easily reviewable, we invoked _get_comp_words_by_ref() in each
>    completion function and systematically replaced every occurance of
>    bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
>    variables set by _get_comp_words_by_ref().
>
>    This has the downside that _get_comp_words_by_ref() is invoked several
>    times during a single completion.  The worst offender is perhaps 'git
>    log mas<TAB>': during the completion of 'master'
>    _get_comp_words_by_ref() is invoked no less than six times.
>
>    However, the variables $prev, $cword, and $words provided by
>    _get_comp_words_by_ref() are not modified in any of the completion
>    functions, and the previous commit ensures that the $cur variable is
>    not modified as well.  This makes it possible to invoke
>    _get_comp_words_by_ref() to get those variables only once in our
>    toplevel completion functions _git() and _gitk(), and all other
>    completion functions will inherit them.
>
>    Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>    Signed-off-by: Junio C Hamano <gitster@pobox.com>

> Pinging Szeder. I personally do not think it is a crime for us to break
> anything that uses an internal function whose name begins with underscore,
> but people more deeply involved in this part of the system may have ideas
> to help supporting even such users.
>
> Nathan Bullock <nathanbullock@gmail.com> writes:
>
>> I have for a number of years had the following in my .bashrc
>>
>> alias br="git branch"
>> complete -F _git_branch br
>>
>> As well as similar commands for co and log.
>>
>> Recently though this broke, now when I type something like "br
>> mas<command completion>" it will occasionally complain with messages
>> like:
>> bash: [: 1: unary operator expected
>>
>> From digging through the source it looks like this was broken back in
>> April. (The commit is show at the bottom of this email.)
>>
>> So my questions are:
>> 1. Is it reasonable for things like _git_branch to work as a
>> standalone autocompletion function instead of having to go through
>> _git? I certainly like it to work as a standalone function. I also use
>> it to add autocompletion to other bash scripts that I use frequently.
>>
>> 2. If I add code that verifies that the variable cword exists at the
>> start of these functions and only if not call something like
>> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> reasonable? I think this should address the performance concerns that
>> caused these to be removed in the first place, but it may make the
>> code uglier.
>>
>> I have already added wrapper functions in my bashrc so that this is no
>> longer a problem for me, but there may be other people who start
>> hitting this as well once they start using newer versions of git.
>>
>> Nathan
>>
>>
>> commit da4902a73017ad82b9926d03101ec69a2802d1e7
>> Author: SZEDER Gábor <szeder@ira.uka.de>
>> Date:   Thu Apr 28 18:01:52 2011 +0200
>>
>>    completion: remove unnecessary _get_comp_words_by_ref() invocations
>>
>>    In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
>>    with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
>>    to access completion-related variables.  That was large change, and to
>>    make it easily reviewable, we invoked _get_comp_words_by_ref() in each
>>    completion function and systematically replaced every occurance of
>>    bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
>>    variables set by _get_comp_words_by_ref().
>>
>>    This has the downside that _get_comp_words_by_ref() is invoked several
>>    times during a single completion.  The worst offender is perhaps 'git
>>    log mas<TAB>': during the completion of 'master'
>>    _get_comp_words_by_ref() is invoked no less than six times.
>>
>>    However, the variables $prev, $cword, and $words provided by
>>    _get_comp_words_by_ref() are not modified in any of the completion
>>    functions, and the previous commit ensures that the $cur variable is
>>    not modified as well.  This makes it possible to invoke
>>    _get_comp_words_by_ref() to get those variables only once in our
>>    toplevel completion functions _git() and _gitk(), and all other
>>    completion functions will inherit them.
>>
>>    Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>>    Signed-off-by: Junio C Hamano <gitster@pobox.com>

> Nathan Bullock <nathanbullock@gmail.com> writes:
> 
> > I have for a number of years had the following in my .bashrc
> >
> > alias br="git branch"
> > complete -F _git_branch br
> >
> > As well as similar commands for co and log.
> >
> > Recently though this broke, now when I type something like "br
> > mas<command completion>" it will occasionally complain with messages
> > like:
> > bash: [: 1: unary operator expected
> >
> > From digging through the source it looks like this was broken back in
> > April. (The commit is show at the bottom of this email.)
> >
> > So my questions are:
> > 1. Is it reasonable for things like _git_branch to work as a
> > standalone autocompletion function instead of having to go through
> > _git? I certainly like it to work as a standalone function. I also use
> > it to add autocompletion to other bash scripts that I use frequently.
> >
> > 2. If I add code that verifies that the variable cword exists at the
> > start of these functions and only if not call something like
> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be
> > reasonable?

> Hi,
>
>
>> Nathan Bullock <nathanbullock@gmail.com> writes:
>>
>> > I have for a number of years had the following in my .bashrc
>> >
>> > alias br="git branch"
>> > complete -F _git_branch br
>> >
>> > As well as similar commands for co and log.
>> >
>> > Recently though this broke, now when I type something like "br
>> > mas<command completion>" it will occasionally complain with messages
>> > like:
>> > bash: [: 1: unary operator expected
>> >
>> > From digging through the source it looks like this was broken back in
>> > April. (The commit is show at the bottom of this email.)
>> >
>> > So my questions are:
>> > 1. Is it reasonable for things like _git_branch to work as a
>> > standalone autocompletion function instead of having to go through
>> > _git? I certainly like it to work as a standalone function. I also use
>> > it to add autocompletion to other bash scripts that I use frequently.
>> >
>> > 2. If I add code that verifies that the variable cword exists at the
>> > start of these functions and only if not call something like
>> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> > reasonable?
>
> That would be too fragile, it will break if $cword is set in the
> environment from which you invoke _git_<cmd>() completion functions
> directly (i.e. not though _git()).
>
>> > I think this should address the performance concerns that
>> > caused these to be removed in the first place, but it may make the
>> > code uglier.
>
> Actually it was not a performance problem, but a cleanup in a patch
> series to fix a zsh-related bug.  Without this cleanup the bugfix
> would have been much more intrusive.
>
>  http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369
>
>
>> > I have already added wrapper functions in my bashrc so that this is no
>> > longer a problem for me, but there may be other people who start
>> > hitting this as well once they start using newer versions of git.
>
> This issue was reported earlier, so it seems there are people who
> would like to use it.  But getting $cur, $cword, etc. variables right
> in _git_<cmd>() completion functions is just part of the problem,
> there are other issues, as mentioned in the previous thread:
>
>  http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232
>
> Unfortunately, I couldn't come up with a solution yet that doesn't
> introduce too much code churn and doesn't cause yet another
> inconsistency between bash and zsh.  I also haven't looked whether
> there are other issues similar to that with _git_fetch() mentioned on
> the above link.