Re: Bug report; git tab-completion on macOS within paths containing unicode characters

[Bart Schaefer <schaefer@brasslantern.com>]

On Mon, Apr 29, 2024 at 5:41 PM Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> > 2024/04/30 2:54、Bart Schaefer <schaefer@brasslantern.com>のメール:
> >
> > On Mon, Apr 29, 2024 at 10:38 AM Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
> >>
> >> In __git_files (called from __git_other_files), 'git ls-files'
> >> is called two times.
> >
> > Comments in the function indicate this is intentional:
>
> Yes, but the second call is just for "better than nothing",
> so the first call should better succeed, I think.

I don't think the first call ever succeeds on files that are not
already known to git, which makes it odd to call it for "git add" in
the first place.  I'm not sure what the intention was here.  Hence my
attempt to call out Daniel.

> I tried
> git ls-files $'/path/to/\xc3\xbc/test2'
> and
> git ls-files $'/path/to/u\xcc\x88/test2'
> but both didn't work. Isn't this a bug of git?

Neither of those worked for me either, even without NFD characters in
the file name, until I was cd'd inside the repository.

It appears that "git ls-files" has to find a .git/ before it will do
any comparisons, even given an absolute path to a(nother) repository.
I don't know whether to class this as a bug in git.