Re: [RFC] Case-insensitive path completion in _git

[Oliver Kiddle <opk@xxxxxxx>]

dana wrote:
> I recently learnt that ls-files actually does support case-insensitive
> matching using the following syntax:
>
>   :(icase)/foo/bar/baz

That applies to the whole path including the directory components which
I don't thing we'd want in this case - but correct me if I'm wrong.

It doesn't appear to support
  /foo/bar/:(icase)baz
The only reference to the feature I could find was in the top-level
git.1 man page so maybe the syntax is different.
You can also pass --icase-pathspecs or set an environment variable.

>     'git ls-files -- /home/dana/linux/'*Kbuild*'' ran
>       1.18 ± 0.04 times faster than 'git ls-files -- ':(icase)'/home/dana/linux/'*kbuild*''
>       2.60 ± 0.09 times faster than 'git ls-files -- /home/dana/linux/'*[Kk][Bb][Uu][Ii][Ll][Dd]*''

That doesn't look too bad at all but I tend not to work in big trees
like the Linux kernel. :(icase) may be worse for a deeper path where
it adds extra directory matches. Did you run these benchmarks on a
case-sensitive or insensitive file-system?

Strictly speaking, we should use * and rely on zsh completion matching
to do the filtering instead of giving git the contents of $PREFIX
anyway but that'd really slow it.

> It could still be gated behind a style if it's a concern.

I don't think thats necessary. Committing as per the original patch
seems good to me.

Oliver