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

["Jun. T" <takimoto-j@xxxxxxxxxxxxxxxxx>]

> 2024/04/30 10:57、Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>のメール:
> 
> On Mon, Apr 29, 2024 at 5:41 PM Jun. T <takimoto-j@xxxxxxxxxxxxxxxxx> wrote:
>> 
>>> 2024/04/30 2:54、Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>のメール:
>>> 
>>> On Mon, Apr 29, 2024 at 10:38 AM Jun. T <takimoto-j@xxxxxxxxxxxxxxxxx> 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,

'git ls-fils --others' gives untracked files.

>> 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.

If there are NFD characters, they do not work even inside the repo.
But I think at least one of them should work.

% cd /path/to/ü
% git ls-files $'/path/to/u\xcc\x88'	# NFD
fatal: /path/to/ü: '/path/to/ü' is outside repository at '/path/to/ü'
(in the error message, the 1st and 2nd ü is NFC, the 3rd is NFD)

I run git within a debugger (lldb), and noticed that, on macOS,
git internally converted the pathspec on the command line (for example
$'/path/to/u\xcc\x88/test2') into NFC. But it treats the top level
working directory name in NFD, so the pathspec (NFC) is considered
as outside of the working tree (NFD).

I will send a bug report to git@xxxxxxxxxxxxxxx.