Linus Torvalds schrieb:
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\002there")
filename2=$(echo -e "hello\003there")
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
