Re: Re-casing directories on case-insensitive systems

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

Kevin Ballard <kevin@sb.org> writes:

> On Jan 11, 2008, at 7:40 PM, Johannes Schindelin wrote:
>
>> On Fri, 11 Jan 2008, Junio C Hamano wrote:
>>
>>> Kevin Ballard <kevin@sb.org> writes:
>>>
>>>> Is there a reason for this? It seems like it would be trivial to end
>>>> up with misdiagnosed "untracked" files when using any language other
>>>> than English given this behaviuor.
>>>
>>> No.  The assumption of the code has always been that sane filesystems
>>> would return from readdir() the names you gave from creat().
>>
>> We do not really have to rehash that whole discussion for the Nth
>> time, do
>> we?
>
> Apparently so. By Junio's definition, HFS+ is not a sane filesystem,
> and as git grows more popular with OS X users, this issue is going to
> crop up more frequently.

It's not "my" definition, but you asked the reason and I gave
the answer.  We can close this issue of "is HFS+ sane" now.
HFS+ is insane, period.  And as Linus said, you cannot forgive
its insanity using the historical baggage argument, like MS-DOS.

HOWEVER.

It is a totally different issue if we want to refuse supporting
insane filesystems.  And the answer is no.  It was not my
intention to say that we do not intend to support them, when I
explained the reason why the things are as they are, which was
the original question by you.

See Robin's proposal to let us translate random names we get
back from readdir() from the filesystem using an additional
look-up table in the index extension section that stores mapping
from canonicalized form to the form that the user registered to
the index.  I think that is a sane approach to tackle this issue
on insane filesystems like HFS+.