> Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> 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., ../contrib/completion/ion.bash ../contrib/git-completion.bash 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 file-completion 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 but > 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 regressions. 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 user and is worth the time needed to fix. Thanks! Marc -- 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