On Fri, 11 Jan 2008, Kevin Ballard wrote: > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
