From: Pedro Melo Date: Thu, 17 Jan 2008 19:02:00 GMT Subject: Re: git on MacOSX and files with decomposed utf-8 file names Message-ID: In-Reply-To: Hi, On Jan 17, 2008, at 6:44 PM, Linus Torvalds wrote: > On Thu, 17 Jan 2008, Pedro Melo wrote: >> >> On Jan 17, 2008, at 6:09 PM, Mark Junker wrote: >> >>> IMHO it would be the best solution when git stores all string >>> meta data in >>> UTF-8 and converts it to the target systems file system encoding. >>> That would >>> fix all those problems with different locales and file system >>> encodings ... >> >> +1. >> >> And I would suggest the use of RFC 3454 as the guidelines for UTF-8 >> normalization. > > The problem is that there is no way to know what the "target system > encoding" is. Correct. Storing or using a normalized version of the filename is only part of the problem. The full problem is: User A <-> filesystem A <-#-> git < ...... > git <-#-> filesystem B <- > user B. You have to encode/decode/normalize on all the <-#-> and there is no magic bullet. Each user would have to tell git "Hey I'm using utf-8" or "Hey, I'm a masochist using HFS+". But I think its important for git to store the filenames in something that at least permits this kind of scenario. All encoding/decoding/normalization is of course optional, and for git, it still is a sequence of bytes. > And it wouldn't actually solve the bigger problem on OS X anyway: > as long > as you are case-insensitive, you'll have all the same problems (ie the > insane OS X filesystem presumably thinks that "MÄRCHEN" and > "Märchen" are > also identical, because they are "equivalent" names). Correct. HFS+ has bigger problems. I'm not sure if this is enough to solve it. But it would solve two linux users using different encodings. And given that the filtering layers are optional, you have to configure them, it wont bite nobody. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: melo@simplicidade.org Use XMPP!