From: Kevin Ballard Date: Sat, 12 Jan 2008 01:16:40 GMT Subject: Re: Re-casing directories on case-insensitive systems Message-ID: In-Reply-To: On Jan 11, 2008, at 7:40 PM, Johannes Schindelin wrote: > On Fri, 11 Jan 2008, Junio C Hamano wrote: > >> Kevin Ballard 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. According to the HFS+ Volume Format technote[1], filenames in HFS+ are stored in normalized, canonical order. To be more specific, they're stored in a special apple variant of Unicode Normal Form D (the special variant is for preserving round-trip with older encodings with certain codepoint ranges[2]). In other words, if you hand an HFS+ filesystem a filename that contains unicode characters, what you get back later may be in a different format. And that's going to be a problem if git doesn't deal with this. [1]: http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties [2]: http://developer.apple.com/qa/qa2001/qa1173.html Note: CC list stripped because this is a re-sent email, as the list bounced the last one that contained a text/html alternate. -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com