Hi,
On Jan 17, 2008, at 6:44 PM, Linus Torvalds wrote:
On Thu, 17 Jan 2008, Pedro Melo wrote:
On Jan 17, 2008, at 6:09 PM, Mark Junker wrote:
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 ...
+1.
And I would suggest the use of RFC 3454 as the guidelines for UTF-8
normalization.
The problem is that there is no way to know what the "target system
encoding" is.
Correct. Storing or using a normalized version of the filename is
only part of the problem.
The full problem is:
User A <-> filesystem A <-#-> git < ...... > git <-#-> filesystem B <-
> user B.
You have to encode/decode/normalize on all the <-#-> and there is no
magic bullet. Each user would have to tell git "Hey I'm using utf-8"
or "Hey, I'm a masochist using HFS+".
But I think its important for git to store the filenames in something
that at least permits this kind of scenario.
All encoding/decoding/normalization is of course optional, and for
git, it still is a sequence of bytes.
And it wouldn't actually solve the bigger problem on OS X anyway:
as long
as you are case-insensitive, you'll have all the same problems (ie the
insane OS X filesystem presumably thinks that "MÄRCHEN" and
"Märchen" are
also identical, because they are "equivalent" names).
Correct. HFS+ has bigger problems. I'm not sure if this is enough to
solve it.
But it would solve two linux users using different encodings.
And given that the filtering layers are optional, you have to
configure them, it wont bite nobody.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@xxxxxxxxxxxxxxxx
Use XMPP!
-
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
