Re: git on MacOSX and files with decomposed utf-8 file names
- From
Kevin Ballard <kevin@sb.org>
- Date
- Jan 18, 2008, 20:24 UTC
- Message-ID
- <2E6F57FC-3E78-4DD2-9B5B-CF75975D6A60@sb.org>
- In-Reply-To
- <alpine.LFD.1.00.0801180909000.2957@woody.linux-foundation.org>
As far as I can tell, the only time you ever run into the problems you've described on a filesystem which treats filenames as unicode strings (and therefore is free to normalize), are when you're trying to interact with a filesystem that treats filenames as sequences of bytes.
This doesn't mean treating filenames as unicode strings is wrong, it just means that the world would be much better if every filesystem had the same behaviour here. It's kinda like the endian issue, except there's no simple solution here.
-Kevin Ballard
On Jan 18, 2008, at 12:11 PM, Linus Torvalds wrote:
Show 23 quoted lines
> On Fri, 18 Jan 2008, Peter Karlsson wrote:
>>
>> But they are not different strings, they are canonically equivalent
>> as
>> far as Unicode is concerned.
>
> Fuck me with a spoon.
>
> Why the hell cannot people see that "equivalent" and "same" are two
> totally different meanings.
>
>> You cannot do a binary comparison of text to see if two strings are
>> equivalent.
>
> .. and this is relevant how? They are different strings. Not the same.
>
> Equivalence doesn't matter. Equivalence is *evil*. Equivalence is what
> gives us case-insensitive filesystems ("because the names are
> equivalent").
>
> Filesystems don't *want* equivalence. They want a much stronger
> exactness
> guarantee. Exactly because sometimes the differences matter.-- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com