Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 5, 2021, 02:12 UTC
Message-ID: <YJH/J+ungqbqT3Zb@camp.crustytoothpaste.net>
In-Reply-To: <xmqqtuni58ra.fsf@gitster.g>

On 2021-05-05 at 00:23:05, Junio C Hamano wrote:

Show 16 quoted lines

> Torsten Bögershausen <tboegi@web.de> writes:
> 
> > To my undestanding we try to rename
> > foo/ into FOO/.
> > But because FOO/ already "exists" as directory,
> > Git tries to move foo/ into FOO/foo, which fails.
> >
> > And no, the problem is probably not restricted to MacOs,
> > Windows and all case-insenstive file systems should show
> > the same, but I haven't tested yet, so it's more a suspicion.
> >
> > The following diff allows to move foo/ into FOO/
> > If someone wants to make a patch out if, that would be good.
> 
> Is strcasecmp() sufficient for macOS whose filesystem has not just
> case insensitivity but UTF-8 normalization issues?

strcasecmp is locale sensitive, so I would say it is not a good choice here. Notably, that means we have differing behavior with "i" and "I" if the locale is Turkish versus English. Only one of those behaviors will be a correct match for what the kernel does, since it is not locale sensitive. Moreover, on Windows, the version of Unicode used for case mapping is written into an NTFS file system when it's created, so a fresh install may have different behavior from an upgrade, and strcasecmp won't honor that.

And, as you pointed out, it doesn't handle Unicode normalization at all.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US