Re: Re-casing directories on case-insensitive systems

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 11, 2008, 22:08 UTC
Message-ID: <alpine.LFD.1.00.0801111356000.3148@woody.linux-foundation.org>
In-Reply-To: <34F43A68-6041-42BE-85BD-3EF971875C0F@sb.org>

On Fri, 11 Jan 2008, Kevin Ballard wrote:

Show 7 quoted lines

> 
> Oh, I'm not surprised git doesn't handle this case, nor do I think git's
> required to. I merely think that, given the increasing relevance of OS X and
> the fact that it uses a case-insensitive system by default, this sort of
> problem is going to occur more and more frequently and it's quite a learning
> experience trying to fix it by hand. It would be very helpful if git could
> detect these problems itself.

I do agree that we could/should do something to help with case-insensitive filesystems.

I absolutely *detest* those things, and I think that people who design them are total morons - with MS-DOS, you could understand it (people didn't know better), but with OS X?

But considering that they exist, we should probably offer at least *some* help for people who didn't realize that you could make OS X behave better.

However, it's not like there is even a simple solution. The right place to do that check would probably be in "add_index_entry()", but doing a check whether the same file already exists (in a different case) is simply *extremely* expensive for a very critical piece of code, unless we were to change that index data structure a lot (ie add a separate hash for the filenames).

Inside the Linux kernel, we have support for insane case-insensitive filesystems, and it really does need a lot of effort to do an even half-way decent thing while not penalizing the sane case. So it's hard.

(And that's totally ignoring the fact that case-insensitivity then also has tons of i18n issues and can get *really* messy - in the above I'm talking purely about the issues that would hit us even with 7-bit straight ASCII).

So handling case-sensitivity (even when you restrict it to ASCII-only) is actually rather messy. The obvious thing to do is to sort everything using a case-insensitive sort, but that in turn would break all the rules git has for the sorting of trees.

So you can't just change the sort order: you'd literally have to have two *different* lookup keys for the index (the "strict sort" and the "case- insensitive sort"), and keep them both around.

Almost all of the code that actually touches the index is in read-cache.c, and it's not like that is a very complex data structure (or a very big file), so adding another key to the sorting probably wouldn't be too horrid. But it's definitely a lot more than just a few lines of code!

		Linus