-----BEGIN PGP SIGNED MESSAGE-----
Il 05/01/2013 21:23, Marc Khouzam ha scritto:
> 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 '/':
> 2- Maybe related to problem 1. Using .. breaks completion in other ways:
> 3- Also probably related to problems 1 and 2. Using absolute paths behaves
> wierdly and
> worse than before:
> In my opinion, the above three cases are regressions.
I did not considered this use case, thanks!
I have never done something like this when working with Mercurial.
The problem is caused by the __git_index_file_list_filter function.
The job of this function is to stop path completion at directory
boundary (in order to avoid to suggest files in child
directories ), and to make paths relative to current directory.
Unfortunately, what it does is to simply remove the prefix string from
the path name; of course this will not work when the prefix is a non
canonical path name.
The solution is quite simple: canonicalize both the prefix path and each
of the path name returned by git.
This can be done using `readlink -f "$path"` or `realpath $path`, but
the problem is that it is inefficient to execute an external command for
each of the path returned by git; moreover readlink and realpath are not
POSIX and may not be supported on all platforms where git works (but I
found a portable implementation using pushd, popd, `pwd`, `dirname`,
`basename` -- not very efficient).
IMHO, the best solution is to recode __git_index_file_list_filter in Perl.
Another possible solution (as suggested by Junio) is to use the
- --relative option; unfortunately this is only supported by
`git diff-index` and not by `git ls-files`.
And it will not solve the problem when using absolute path names (but
this case can be handled by leaving path completion to bash).
> 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 is another thing I missed.
The problem is that only the current directory is removed from the path
names returned by git.
> 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.
The fix was very easy, and it seems to work.
The problem is in the __git_complete_index_files and
When calling the __git_index_files and git_index_files, the "$cur"
variable should be used, instead of the computed "$pfx".
Not sure if this is correct.
I will post the patch, so you can test it.
> 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
I'll pass on this, thanks.
> 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
And there are other places when it may be useful to check the passed
options (see the comments).
But I think it is better to leave these issues for the future.
I will just add a comment to take note of this use case.
> 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.
Not sure how this can be done, but it is possible and should be easy.
> 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.
Thanks to you for the review!
 this is what the Mercurial bash completion script does
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
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