> Junio C Hamano <gits...@pobox.com> writes:
>>  Marc Khouzam <marc.khou...@ericsson.com> writes:
>>> I've been playing with it but I'm not getting the expected
>>> behavior when I cd to a sub-directory.
>> Thanks for testing.  Manlio?
> Can you try the attached patch?

Thanks for this, it improves the situation dramatically.
I did further testing with your patch and found some less obvious
issues.  I didn't debug the script myself as I'm not that familiar with
it either, but I think the testcases below should help Manlio or
someone else look into some regressions.

1- Using .. or . breaks completion when after the '/':
> cd git/contrib
> git rm ../contrib/completion/<tab>
../contrib/completion/ion.bash  ../contrib/completion/ion.tcsh  
../contrib/completion/ion.zsh   ../contrib/completion/sh
It looks like the space taken by the path where we are located, eats up the 
same number of characters from the file name, e.g.,

2- Maybe related to problem 1.  Using .. breaks completion in other ways:
> cd git/contrib
> git rm ../con<tab>
../config.c       ../config.mak.in  ../configure.ac   ../connect.c      
../connected.c    ../connected.h    ../convert.c      ../convert.h
Notice that 'contrib' is not proposed.
Don't be fooled by the fact that
> git rm ../cont<tab>
will complete to 
> git rm ../contrib
as it is only because the completion script returned nothing, and bash 
kicked-in instead (it fooled me :)).

3- Also probably related to problems 1 and 2.  Using absolute paths behaves 
wierdly and 
worse than before:
git rm /home/marc/git/git/con<tab>
will give
git rm /home/marc/git/git/config-
although there is the 'contrib' dir that should be shown, amongst others.
Seems like the same problem as above with 'git rm ../con<tab>'

In my opinion, the above three cases are regressions.

4- Completion choices include their entire path, which is not what bash does by 
default.  For example:
> cd git/contrib
> ls completion/git-<tab>
git-completion.bash  git-completion.tcsh  git-completion.zsh   git-prompt.sh
> git rm completion/git-<tab>
completion/git-completion.bash  completion/git-completion.tcsh  
completion/git-completion.zsh   completion/git-prompt.sh
notice the extra 'completion/' before each completion.  This can get pretty 
large when completing with 
many directory prefixes.  The current tcsh completion has the same problem 
which I couldn't fix.  However, I am 
not sure if it can be fixed for bash.

I personally don't think this is regression, just an slight annoyance.

5- With this feature git-completion.bash will return directories as 
completions.  This is something
git-completion.tcsh is not handling very well.  I will post a patch to fix that.

Below are two suggestions that are in line with this effort but that are not 

A) It would be nice if 
git commit -a <TAB>
also completed with untracked files

B) Now that, for example, 'git rm' completion is smart about path completion 
it would be nice to somehow not trigger bash default file completion
when 'git rm' does not report any completions.  

For example, if I have a file called zz.tar.gz (which is an ignored file) 
and I do 'git rm <tab>', I will get the proper list of files that can be
removed by git, excluding zz.tar.gz.  But if I complete
'git rm zz.tar.<tab>' then the completion script will return nothing,
since git cannot remove that ignored file, but we will then fall-back
to the bash default completion, which will complete the file to zz.tar.gz.

Although there are some issues, I think this feature will greatly benefit the 
and is worth the time needed to fix.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to