Re: Re [bug] pull --prune could not delete references due to lock file already exists error

[Junio C Hamano <gitster@pobox.com>]

Chris Torek <chris.torek@gmail.com> writes:

> On Mon, Jun 30, 2025 at 7:21 AM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> [regarding]
>> > +                             if (ignore_case && prev && !strcasecmp(ref->next, prev))
>> This won't work in the general case, since the two refs that match case
>> insensitively aren't guaranteed to be adjacent.
>
> Also worth mention: it's not just case-folding that matters.
>
> On OS X (Macs), path names get "normalized" so that the names
>
>    s c h combining-umlaut o n
>
> and
>
>    s c h umlaut-o n
>
> refer to the *same* file or directory. On a typical Linux/Unix FS, they differ.
>
> (I don't know what Windows does!)
>
> So, if you have a "folder-full" of "pretty" German refnames, some
> spelled one way and some another, well...
>
> (It's not clear to me what, if anything, Git should attempt to do here.)

The system supplied argv[] is fed to the precompose_argv_prefix()
helper in compat/precompose_utf8.c; opendir/readdir/closedir are
also wrapped with similar NFD/NFC normalization (really, UTF-8-MAC
vs UTF-8) helpers defined in the same file.  So the path you read
(via the opendir/readdir like dir.c does) from the system, or the
path you are fed from the command line (via argv[]), are normalized
before code in Git above the compat layer even sees them.  The path
recoreded in various mechanisms in Git like the index and the tree
objects are all normalized.