2012/1/24 SZEDER Gábor <szeder@xxxxxxxxxx>: > Hi, > > >> Nathan Bullock <nathanbullock@xxxxxxxxx> 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. At the end of this thread that you refer to, http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232, there is a set of wrapper functions that look reasonably good for solving this problem. There was a question if those could be included in the main git code base. Do you know if that is likely to happen? Nathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html