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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 17, 2008, 00:25 UTC
Message-ID: <alpine.LFD.1.00.0801161619420.2806@woody.linux-foundation.org>
In-Reply-To: <B45968C6-3029-48B6-BED2-E7D5A88747F7@sb.org>

On Wed, 16 Jan 2008, Kevin Ballard wrote:

> 
> My understanding is that normalization is there to help the computer. That
> doesn't give it any semantic meaning, because all normal forms of a given
> string still represent the exact same string to the user.

THAT IS NOT TRUE!

How the hell does the computer know what the string means?

Hint: it does not.

The fact is, the user may use a non-normalized string on purpose. It's not your place to say that the user is wrong. Your "undestanding" is simply wrong. Two strings are *different* if they are [un]normalized differently.

Really.

The exact same way the word Polish and polish are different, just because they are capitalized differently.

> The argument for case insensitivity is different than the argument for
> normalization. I certainly hope you understand why they are different
> arguments, or there's really no point in going further.

You do not understand.

In *order* to do case-insensitivity, you generally need to normalize (and do other things too - normalization is just *one* of the things you need to do).

So if you are a case-insensitive filesystem, then normalization is sane.

But if you aren't, then there is no reason to normalize.

> You're right, sometimes the sequence matters. As in key sequences. But we're
> not talking about key sequences, we're talking about strings.

You define "string" to be something totally made-up.

In your world "string" means "normalized". BUT IT'S NOT TRUE!

You define normalization to be a property of strings, without any actual backing for why that would be.

The fact is, *looks the same* is very very different from *is the same*.

But you seem to be too stupid to undestand the differce.

		Linus