Dear diary, on Sun, Oct 08, 2006 at 05:52:10PM CEST, I got a letter where Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> said that... > *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. There is a tradeoff here between independence of the data stored inside Git on the system where you created it, and willingness to store any awful garbage you feed inside. It goes down to a policy decision and Git lefts it on the user and opting for garbage support, which gives it more flexibility. > söndag 08 oktober 2006 12:16 skrev Jakub Narebski: > > 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. Incorrect, Git manages only the execute bit. > > 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? Execute bit isn't content at all either if you look at it this way. But it's meaningless anyway since you can define content whichever way you want (this is also why I consider the argument for not tracking directories dubious). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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