> When filtering the ls-files output we take care not to touch absolute
> paths. This is redundant, because ls-files will never output absolute
> paths. Furthermore, sorting the output is also redundant, because the
> output of ls-files is already sorted.
>
> Remove the unnecessary operations.
You didn't run the test suite, did you? ;)
First, neither 'git ls-files' nor 'git diff-index' produce quite the
same order as the 'sort' utility does, e.g.:
$ touch foo.c foo-zzz.c
$ git add foo*
$ git diff-index --name-only HEAD
foo-zzz.c
foo.c
$ git diff-index --name-only HEAD |sort
foo.c
foo-zzz.c
Second, the output of 'git ls-files' is kind of "block-sorted": if you
were to invoke it with the options '--cached --modified --others',
then it will first list all untracked files in order, then all cached
files in order, and finally all modified files in order. Note the
implications:
- A file could theoretically be listed twice, because a modified
file is inherently cached as well. I believe this doesn't happen
currently, because no path completions use the combination of
'--modified --cached', but we use a lot of options when completing
paths for 'git status', and I haven't thought that through.
- A directory name is repeated in two (or more) blocks, if it
contains modified and untracked files as well. We do use the
combination of '--modified --others' for 'git add', and '--cached
--others' for 'git mv', so this does happen.
Note also that there can be any number of other files between the same
directory listed in two different blocks. That 'sort' that this patch
is about to remove took care of this, but without that 'sort' the same
directory name can be listed more than once even after 'uniq'.
Consequently, the subsequent filtering of paths matching the current
word to be completed might have twice as much work to do.
All this leads to the failure of an enormous test in t9902, hence my
rethorical question at the beginning of my reply.
I have a short patch series collecting dust somewhere for a long
while, which pulls a couple more tricks to make git-aware path
completion faster, but haven't submitted it yet, because it doesn't
work quite that well when filenames require quoting. Though, arguably
the current version doesn't work quite that well with quoted filenames
either, so...
Will try to dig up those patches.
> Signed-off-by: Clemens Buchacher <dri...@gmx.net>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index e3ddf27..394c3df 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -384,7 +384,7 @@ __git_index_files ()
> local root="${2-.}" file
>
> __git_ls_files_helper "$root" "$1" |
> - sed -e '/^\//! s#/.*##' | sort | uniq
> + cut -f1 -d/ | uniq
> }
>
> # Lists branches from the local repository.
> --
> 2.7.4
>
>
