söndag 08 oktober 2006 12:16 skrev Jakub Narebski: > File content encoding is something (if it is outside US-ASCII of course) > that you would want either to have some default convention, or have it > embedded in the file itself (like XML, HTML, or Emacs' file variables) > to be able to read file _outside_ SCM. Except for CR/LF, this is best solved outside of the SCM. There aren't that may tools/users to warrant the complexity or performance hit I imagine to solve it. > Path name encoding is something that is global property of a repository, > I think. We have i18n.commitEncoding configuration variable; we could > add i18n.pathnameEncoding quite easily I think (and some way for Git to > detect current filesystem pathname encoding, if possible). Although > BTW I think that i18n.commitEncoding information should be made persistent, > and copied when cloning repository. *I* think git should use UTF-8 internally. Always. Clients could then have the option to convert to local conventions. Same for pathname. Internally all paths should be UTF-8 encoded. Encoding commit info that way would make the i18n option obsolete also. I have a patch for both these, but it's very ugly and probably has some memory management problems, so I'll refrain from submitting for now. Knowing that it exists may perhaps serve as starting point for discussion. It encodes filenames in UTF-8 using LC_CTYPE as the local encoding, as well as commit messages. An exception is when something looks like UTF-8, in which case it will not convert input to git. When UTF-8 cannot be converted to the local encoding on it's way out of git, the data remains in UTF-8 format. Branch and tags names are not managed (yet, at least). > But in fact the philosophy of Git _prohibits_ I think property bits. I don't think so, but they aren't needed for the original purpose. Git already does manage file permissions. > Unless we add ability (which can be done fairly easy even now, but will > not be automatic) to save some metainfo (ACL, extended attributes, > Subversion-like properties) along with the file (blob) and/or tree > (directory). A problem with adding too much metadata is that there is a cost to this. We like GIT much thanks to it's perforrmance. Git simply gets out of the way thanks to this. ACL's aren't content at all. Extended attributes however are, but who uses them? -- robin - 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