Linus Torvalds schrieb:

quoted text
> In other words, on a bog-standard UNIX (and yes, in this case, I bet OS X 
> works fine too for this test), just try this
> 
> 	filename1=$(echo -e "hello__PLACEHOLDER__0_2there")
> 	filename2=$(echo -e "hello__PLACEHOLDER__0_3there")
> 	echo Odd file > "$filename1"
> 	echo Another odd file > "$filename2"
> 
> and now you have a filename that is actually rather hard to type on the 
> command line. In fact, for me they even *look* the same:
> 
> 	[torvalds@woody ~]$ ll hello*
> 	-rw-rw-r-- 1 torvalds torvalds  9 2008-01-17 08:23 hello?there
> 	-rw-rw-r-- 1 torvalds torvalds 17 2008-01-17 08:23 hello?there
> 
> See?

Sorry, but you're using different characters that look the same. But 
Kevins point was that it's a different thing if you use two characters 
that look the same or the same character with different encodings. This 
makes this HFS-specific problem different from the "look the same"- or 
the "case-insensitivity"-issues.

BTW: I also read about your argument that you wouldn't convert file data 
to normalized UTF-8 (I agree with you that this would be nonsense) and 
therefore filenames shouldn't be converted too. This is something where 
I have to disagree because a filename (like ctime, mtime, atime, ...) 
are meta data (while file contents isn't) and - until now - I would've 
guessed that you agree on this point because git doesn't care about 
filenames but contents.

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 ...

However, I have to agree that the enforced character set conversion 
causes more problems than it solves.

Regards,
Mark
-
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