Re: git on MacOSX and files with decomposed utf-8 file names

["Martin Langhoff" <martin.langhoff@gmail.com>]

On Jan 22, 2008 9:53 AM, Kevin Ballard <kevin@sb.org> wrote:
> On Jan 21, 2008, at 3:33 PM, Linus Torvalds wrote:
> > Umm. What's this inability to see that data is data is data?
>
> I'm not sure what you mean. I stated a fact - at least on OS X, the
> filename does not contribute to the listed filesize, so changing the
> encoding of the filename doesn't change the filesize. This isn't a
> philosophical point, it's a factual statement.

Kevin,

as you might know, Linus' "other hobby" is to write kernels ;-) From
taht POV, a filename is as much data as the data in the file. Doing
odd things like sorting it, searching through it, etc, is all work for
code higher in the stack that is free to mangle the data in any way it
wants, including creating nice case-insensitive indexes, and
who-knows-what for ideogram-based languages. In contrast, the core OS
treats user data a sacred stuff, and I'm thankful it does.

And from a kernel/filesystem POV, a directory is also a file. So if a
filename has a different number of octets, the directory will be
different.

For all the searching and matching, it really makes sense to have
something like locate or SpotLight or whatever to index user files
that should be easy to find and match, because all the locale rules
for matching are hideously expensive to apply. Even today, most UTF-8
aware (and supposedly collation-smart) applications have trouble
matching MARTÍN when asked for martín in a case-insensitive search.
That pesky latin í trips them up everytime.

cheers,


martin