On Wed, 16 Jan 2008, Kevin Ballard wrote:
quoted text
> 
> There's a difference between "looks similar" as in "Polish" vs "polish", and
> actually is the same string as in "Ma<UMLAUT MODIFIER>rchen" vs "M<A WITH
> UMLAUT>rchen". Capitalization has a valid semantic meaning, normalization
> doesn't. 

That simply isn't true.

Normalization actually has real semantic meaning. If it didn't, there 
would never ever be a reason why you'd use the non-normalized form in the 
first place.

Others have argued the exact same thing for capitalization. "A" is the 
same letter as "a". Except there is a distinction.

The same is true of "a<UMLAUT MODIFIER>" and "<a WITH UMLAUT>". Yes, it's 
the same "chacter" in either case. Except when there is a distinction.

And there *are* cases where there are distinctions. Especially inside 
computers. For one thing, you may not be talking about "characters on 
screen", but you may be talking about "key sequences". And suddenly 
"a<UMLAUT MODIFIER>" is a two-key sequence, and "<a WITH UMLAUT>" is a 
single-key sequence, and THEY ARE DIFFERENT.

See?

"a" and "A" are the same letter. But sometimes case matters.

Multi-character UTF-8 sequences may be the same character. But sometimes 
the sequence matters.

Same exact thing.

quoted text
>	The only way to argue that normalization is wrong is by providing a
> good reason to preserve the exact byte sequence, and so far the only reason
> I've seen is to help git.

Git doesn't care. Just use the *same* sequence everywhere. Make sure 
something doesn't change it. Because if something changes it, git will 
track it.

quoted text
> How do you figure? When I type "Märchen", I'm typing a string, not a byte
> sequence. I have no control over the normalization of the characters.
> Therefore, depending on what program I'm typing the name in, I might use the
> same normalization as the filename, or I might miss. It's completely out of my
> control. This is why the filesystem has to step in and say "You composed that
> character differently, but I know you were trying to specify this file".

Pure and utter garbage.

What you are describing is an *input method* issue, not a filesystem 
issue.

The fact that you think this has anything what-so-ever to do with 
filesystems, I cannot understand.

Here's an example: I can type Märchen two different ways on my keyboard: I 
can press the 'ä' key (yes, I have one, I have a Swedish keyboard), or I 
could press the '¨' key and the 'a' key.

See: I get 'ä' and 'ä' respectively.

And as I send this email off, those characters never *ever* got written as 
filenames to any filesystem. But they *did* get written as part of 
text-files to the disk using "write()", yes.

And according to your *insane* logic, that write() call should have 
converted them to the same representation, no?

Hell no! That conversion has absolutely nothing to do with the filesystem. 
It's done at a totally different layer that actually knows what it is 
doing, and turned them both into \xc3\xa4 (and then, the email client 
probably will turn this into Latin1, and send it out as a single-byte 
'\xe4' character).

See? Putting the conversion in the filesystem IS INSANE. You wouldn't make 
the filesystem convert the characters in the data stream (because it would 
cause strange data conversion issues) AND FOR EXACTLY THE SAME REASON it 
shouldn't do it for filenames either!

And your claim that "you have no control over the normalization of 
characters" is simply insane. Of course you have. It's just not supposed 
to be at the filesystem level - whether it's a write() call or a creat() 
call!

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html