{"thread":{"id":"5855","subject":"Does GIT require property like Subversion?","startedAt":"2006-10-08T09:10:51Z","lastAt":"2006-10-09T02:53:59Z","messageCount":8,"participants":["Liu Yubao","Jan-Benedict Glaw","Jakub Narebski","Robin Rosenberg","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28410","messageId":"4528C09B.3030004@gmail.com","threadId":"5855","inReplyTo":null,"subject":"Does GIT require property like Subversion?","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-10-08T09:10:51Z","receivedAt":"2006-10-08T09:10:51Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"I want to know whether there is a plan to add this feature, or GIT doesn't\nrequire it at all.\n\nProperties like encoding (path name, file content), eol-style, mime-type\nare useful for editing.\n\nBTW: I don't mean Subversion is better that GIT:-)\n"},{"id":"28411","messageId":"20061008091900.GG30283@lug-owl.de","threadId":"5855","inReplyTo":"4528C09B.3030004@gmail.com","subject":"Re: Does GIT require property like Subversion?","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-10-08T09:19:00Z","receivedAt":"2006-10-08T09:19:00Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-10-08 17:10:51 +0800, Liu Yubao wrote:\n> I want to know whether there is a plan to add this feature, or GIT doesn't\n> require it at all.\n> \n> Properties like encoding (path name, file content), eol-style, mime-type\n> are useful for editing.\n\nGIT is a content tracker. It won't ever fiddle with your line\nendings. You put data in there and it'll be conserved bit-by-bit. So\nif you need to store file encodings, MIME types, automatic CR/CRLF/LF\nconverstion etc, you have to put this metadata into some additional\nfiles, but GIT won't specifically handle that in any way.\n\nMfG, JBG\n\n-- \n Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481\nSignature of: Eine Freie Meinung in einem Freien Kopf\nthe second : für einen Freien Staat voll Freier Bürger.\n"},{"id":"28415","messageId":"egaj49$424$1@sea.gmane.org","threadId":"5855","inReplyTo":"20061008091900.GG30283@lug-owl.de","subject":"Re: Does GIT require property like Subversion?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-08T10:16:26Z","receivedAt":"2006-10-08T10:16:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan-Benedict Glaw wrote:\n\n> On Sun, 2006-10-08 17:10:51 +0800, Liu Yubao wrote:\n>> I want to know whether there is a plan to add this feature, or GIT doesn't\n>> require it at all.\n>> \n>> Properties like encoding (path name, file content), eol-style, mime-type\n>> are useful for editing.\n> \n> GIT is a content tracker. It won't ever fiddle with your line\n> endings. You put data in there and it'll be conserved bit-by-bit. So\n> if you need to store file encodings, MIME types, automatic CR/CRLF/LF\n> converstion etc, you have to put this metadata into some additional\n> files, but GIT won't specifically handle that in any way.\n\nMimetype has no place (I think) in SCM. We could in pronciple \"borrow\"\nMercurial idea of input/output filters\n http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter\nwhich would (among others) enable to use constant eol-style in the shared\npart of repository i.e. object database, while using OS native eol-style\n(UNIX vs. Microsoft Windows vs. MacOS). eol-style doesn't matter much:\nyou can find good editors which are able to use any eol-style for any OS\nnowadays.\n\nFile content encoding is something (if it is outside US-ASCII of course)\nthat you would want either to have some default convention, or have it\nembedded in the file itself (like XML, HTML, or Emacs' file variables)\nto be able to read file _outside_ SCM.\n\nPath name encoding is something that is global property of a repository,\nI think. We have i18n.commitEncoding configuration variable; we could\nadd i18n.pathnameEncoding quite easily I think (and some way for Git to\ndetect current filesystem pathname encoding, if possible). Although\nBTW I think that i18n.commitEncoding information should be made persistent,\nand copied when cloning repository.\n\n\nBut in fact the philosophy of Git _prohibits_ I think property bits.\nUnless we add ability (which can be done fairly easy even now, but will\nnot be automatic) to save some metainfo (ACL, extended attributes,\nSubversion-like properties) along with the file (blob) and/or tree\n(directory).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28416","messageId":"egajm5$424$2@sea.gmane.org","threadId":"5855","inReplyTo":"egaj49$424$1@sea.gmane.org","subject":"Re: Does GIT require property like Subversion?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-08T10:26:04Z","receivedAt":"2006-10-08T10:26:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> We could in pronciple \"borrow\" Mercurial idea of input/output filters\n>   http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter\n> which would (among others) enable to use constant eol-style in the shared\n> part of repository i.e. object database, while using OS native eol-style\n> (UNIX vs. Microsoft Windows vs. MacOS). eol-style doesn't matter much:\n> you can find good editors which are able to use any eol-style for any OS\n> nowadays.\n\nWhat's more important, that would enable to store in SCM files which format\nis of archive of mix of _text_ and binary files, archive being compressed\nand binary. Examples include OpenDocument (ODF), Java Archive (.jar),\nMozilla extension (.xpi)... well good XML aware diff would be also nice.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28424","messageId":"200610081752.10940.robin.rosenberg.lists@dewire.com","threadId":"5855","inReplyTo":"egaj49$424$1@sea.gmane.org","subject":"Re: Does GIT require property like Subversion?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-10-08T15:52:10Z","receivedAt":"2006-10-08T15:52:10Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 oktober 2006 12:16 skrev Jakub Narebski:\n> File content encoding is something (if it is outside US-ASCII of course)\n> that you would want either to have some default convention, or have it\n> embedded in the file itself (like XML, HTML, or Emacs' file variables)\n> to be able to read file _outside_ SCM.\nExcept for CR/LF, this is best solved outside of the SCM. There aren't that\nmay tools/users to warrant the complexity or performance hit I imagine to \nsolve it.\n\n> Path name encoding is something that is global property of a repository,\n> I think. We have i18n.commitEncoding configuration variable; we could\n> add i18n.pathnameEncoding quite easily I think (and some way for Git to\n> detect current filesystem pathname encoding, if possible). Although\n> BTW I think that i18n.commitEncoding information should be made persistent,\n> and copied when cloning repository.\n\n*I* think git should use UTF-8 internally. Always. Clients could then have\nthe option to convert to local conventions.\n\nSame for pathname. Internally all paths should be UTF-8 encoded. Encoding \ncommit info that way would make the i18n option obsolete also.\n\nI have a patch for both these, but it's very ugly and probably has some memory \nmanagement problems, so I'll refrain from submitting for now. Knowing that it \nexists may perhaps serve as starting point for discussion. It encodes \nfilenames in UTF-8 using LC_CTYPE as the local encoding, as well as commit \nmessages. An exception is when something looks like UTF-8, in which case it \nwill not convert input to git. When UTF-8 cannot be converted to the local \nencoding on it's way out of git, the data remains in UTF-8 format. Branch and \ntags names are not managed (yet, at least).\n\n> But in fact the philosophy of Git _prohibits_ I think property bits.\nI don't think so, but they aren't needed for the original purpose. Git already\ndoes manage file permissions.\n\n> Unless we add ability (which can be done fairly easy even now, but will\n> not be automatic) to save some metainfo (ACL, extended attributes,\n> Subversion-like properties) along with the file (blob) and/or tree\n> (directory).\n\nA problem with adding too much metadata is that there is a cost to this. We \nlike GIT much thanks to it's perforrmance. Git simply gets out of the way \nthanks to this. ACL's aren't content at all. Extended attributes however are, \nbut who uses them?\n\n\n-- robin\n"},{"id":"28425","messageId":"20061008162410.GK20017@pasky.or.cz","threadId":"5855","inReplyTo":"200610081752.10940.robin.rosenberg.lists@dewire.com","subject":"Re: Does GIT require property like Subversion?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-10-08T16:24:10Z","receivedAt":"2006-10-08T16:24:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Oct 08, 2006 at 05:52:10PM CEST, I got a letter\nwhere Robin Rosenberg said that...\n> *I* think git should use UTF-8 internally. Always. Clients could then have\n> the option to convert to local conventions.\n> \n> Same for pathname. Internally all paths should be UTF-8 encoded. Encoding \n> commit info that way would make the i18n option obsolete also.\n\nThere is a tradeoff here between independence of the data stored inside\nGit on the system where you created it, and willingness to store any\nawful garbage you feed inside. It goes down to a policy decision and Git\nlefts it on the user and opting for garbage support, which gives it more\nflexibility.\n\n> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:\n> > But in fact the philosophy of Git _prohibits_ I think property bits.\n> I don't think so, but they aren't needed for the original purpose. Git already\n> does manage file permissions.\n\nIncorrect, Git manages only the execute bit.\n\n> > Unless we add ability (which can be done fairly easy even now, but will\n> > not be automatic) to save some metainfo (ACL, extended attributes,\n> > Subversion-like properties) along with the file (blob) and/or tree\n> > (directory).\n> \n> A problem with adding too much metadata is that there is a cost to this. We \n> like GIT much thanks to it's perforrmance. Git simply gets out of the way \n> thanks to this. ACL's aren't content at all. Extended attributes however are, \n> but who uses them?\n\nExecute bit isn't content at all either if you look at it this way. But\nit's meaningless anyway since you can define content whichever way you\nwant (this is also why I consider the argument for not tracking\ndirectories dubious).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Dear diary, on Sun, Oct 08, 2006 at 05:52:10PM CEST, I got a letter\n> where Robin Rosenberg said that...\n>> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:\n\n>>> But in fact the philosophy of Git _prohibits_ I think property bits.\n\n>> I don't think so, but they aren't needed for the original purpose. Git\n>> already does manage file permissions.\n> \n> Incorrect, Git manages only the execute bit.\n\nAnd symlinks.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28443","messageId":"4529B9C7.7000000@gmail.com","threadId":"5855","inReplyTo":"200610081752.10940.robin.rosenberg.lists@dewire.com","subject":"Re: Does GIT require property like Subversion?","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-10-09T02:53:59Z","receivedAt":"2006-10-09T02:53:59Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Sorry, I forgot to reply all.\n\nRobin Rosenberg wrote:\n> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:\n>> File content encoding is something (if it is outside US-ASCII of course)\n>> that you would want either to have some default convention, or have it\n>> embedded in the file itself (like XML, HTML, or Emacs' file variables)\n>> to be able to read file _outside_ SCM.\n> Except for CR/LF, this is best solved outside of the SCM. There aren't that\n> may tools/users to warrant the complexity or performance hit I imagine to \n> solve it.\n> \n>> Path name encoding is something that is global property of a repository,\n>> I think. We have i18n.commitEncoding configuration variable; we could\n>> add i18n.pathnameEncoding quite easily I think (and some way for Git to\n>> detect current filesystem pathname encoding, if possible). Although\n>> BTW I think that i18n.commitEncoding information should be made persistent,\n>> and copied when cloning repository.\n> \n> *I* think git should use UTF-8 internally. Always. Clients could then have\n> the option to convert to local conventions.\n> \n> Same for pathname. Internally all paths should be UTF-8 encoded. Encoding \n> commit info that way would make the i18n option obsolete also.\n> \nI am afraid it's not a good idea to convert file content to UTF-8 encoding\nas GIT can manage non-text file, it's not safe to modify file content \nstealthily by a VCS.\n\nBut I agree to use UTF-8 for path name in tree object, or add an encoding\nproperty(not a user defined property) to the head of tree object, so GIT\nwon't do useless enc -> UTF-8 -> same_enc conversion. The second way has\na fault: two tree objects with same content in different encoding have \ndifferent SHA1 digests.\n\n> I have a patch for both these, but it's very ugly and probably has some memory \n> management problems, so I'll refrain from submitting for now. Knowing that it \n> exists may perhaps serve as starting point for discussion. It encodes \n> filenames in UTF-8 using LC_CTYPE as the local encoding, as well as commit \n> messages. An exception is when something looks like UTF-8, in which case it \n> will not convert input to git. When UTF-8 cannot be converted to the local \n> encoding on it's way out of git, the data remains in UTF-8 format. Branch and \n> tags names are not managed (yet, at least).\n> \n >\nGood, hope GIT can deal with path names that are not in 8859_1 or UTF-8 encoding.\n"}]}