{"thread":{"id":"16606","subject":"why not preserve file permissions?","startedAt":"2008-12-05T20:08:08Z","lastAt":"2008-12-06T01:29:14Z","messageCount":5,"participants":["jidanni@jidanni.org","Jakub Narebski","Junio C Hamano","Daniel Barkalow","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97213","messageId":"87tz9igzbr.fsf@jidanni.org","threadId":"16606","inReplyTo":null,"subject":"why not preserve file permissions?","fromName":"","fromEmail":"jidanni@jidanni.org","sentAt":"2008-12-05T20:08:08Z","receivedAt":"2008-12-05T20:08:08Z","isPatch":false,"sender":{"key":"jidanni@jidanni.org","avatar":"https://gravatar.com/avatar/36568d4af4c8d3e71627ef3b8c8d00e39065b12f29676cccd38ced75e68fa2a6?d=mp&s=160"},"body":"Why not preserve permissions the way you find them, instead of just\nusing 644 and 755? It certainly couldn't be more complicated than what\nyou are doing now, and that way one could do things like use git to\nupdate system administration files across a sneakernet containing e.g.,\n# dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u\n-rw-r-----\n-rw-r--r--\n-rwxr-xr-x\n\n> git was made for tracking source code, not 640 files.\n\nOn the sneakernet no public patches would be sent, and the\nadministrator would remember to make the sensitive .git directories\n700. And sure, git should enforce umask or no set-uid or whatever when\ndoing a checkout etc. The deluxe edition of git could even print a\nwarning: \"you are trying to track a 640 file but your .git permissions\nare less restrictive.\" However I recommend no premium or deluxe\neditions for now.\n\n> Patches welcome.\n\nTrust me, you don't want \"grandpa who forgot the parking brake\"\nanywhere near your code.\n"},{"id":"97222","messageId":"m38wqui7lz.fsf@localhost.localdomain","threadId":"16606","inReplyTo":"87tz9igzbr.fsf@jidanni.org","subject":"Re: why not preserve file permissions?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-05T22:23:55Z","receivedAt":"2008-12-05T22:23:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"jidanni@jidanni.org writes:\n\n> Why not preserve permissions the way you find them, instead of just\n> using 644 and 755? It certainly couldn't be more complicated than what\n> you are doing now, and that way one could do things like use git to\n> update system administration files across a sneakernet containing e.g.,\n> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u\n> -rw-r-----\n> -rw-r--r--\n> -rwxr-xr-x\n> \n> > git was made for tracking source code, not 640 files.\n> \n> On the sneakernet no public patches would be sent, and the\n> administrator would remember to make the sensitive .git directories\n> 700. And sure, git should enforce umask or no set-uid or whatever when\n> doing a checkout etc. The deluxe edition of git could even print a\n> warning: \"you are trying to track a 640 file but your .git permissions\n> are less restrictive.\" However I recommend no premium or deluxe\n> editions for now.\n\nGit was made for tracking _source code_ among _different_ machines, as\na way to collaborate in development.  This means that different users\nof the same repository can have and usually have different user,\ndifferent user-id, different group, and perhaps different group\npermission settings on a files.  Git supports only ordinary files,\nexecutable ordinary files, directories and symbolic links for\na reason: otherwise it would be very easy to propagate spurious\npermission changes because some contributor has different setup.\n\nSide note: git can be used on operating systems / with filesystems\nwhich do not have UNIX notion of permissions (think MS Windows).\n\n\nAlso changes _now_ to the repository format (and keeping full\npermissions would require changing format of 'tree' objects) would\nhave to be extremely well substantiated.  And using git to store\nsystem administration files, as a kind of cross between (amost) single\nmachine version control and backup system is possible even now: see\nEtckeeper and IsiSetup tools (you can find them at git wiki at\nhttp://git.or.cz/gitwiki/InterfacesFrontendsAndTools page).  Or you\ncan use tools like CFEngine...\n\nHTH.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97225","messageId":"7vljuuxn66.fsf@gitster.siamese.dyndns.org","threadId":"16606","inReplyTo":"87tz9igzbr.fsf@jidanni.org","subject":"Re: why not preserve file permissions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-05T22:38:41Z","receivedAt":"2008-12-05T22:38:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"jidanni@jidanni.org writes:\n\n> Why not preserve permissions the way you find them, instead of just\n> using 644 and 755? It certainly couldn't be more complicated than what\n> you are doing now, and that way one could do things like use git to\n> update system administration files across a sneakernet containing e.g.,\n> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u\n> -rw-r-----\n> -rw-r--r--\n> -rwxr-xr-x\n\nActually in a very early days, git used to record the full (mode & 0777)\nfor blobs.\n\nOnce people started using git, everybody realized that it had a very\nunpleasant side effect that the resulting tree depended on user's umasks,\nbecause one person records a blob with mode 664 and the next person who\nmodifies the file would record with mode 644, and it made it very hard to\nkeep track of meaningful changes to the source code.  This issue was fixed\nlong time ago with commit e447947 (Be much more liberal about the file\nmode bits., 2005-04-16).\n"},{"id":"97227","messageId":"alpine.LNX.1.00.0812051815240.19665@iabervon.org","threadId":"16606","inReplyTo":"87tz9igzbr.fsf@jidanni.org","subject":"Re: why not preserve file permissions?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-12-06T00:05:20Z","receivedAt":"2008-12-06T00:05:20Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 6 Dec 2008, jidanni@jidanni.org wrote:\n\n> Why not preserve permissions the way you find them, instead of just\n> using 644 and 755? It certainly couldn't be more complicated than what\n> you are doing now, and that way one could do things like use git to\n> update system administration files across a sneakernet containing e.g.,\n> # dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u\n> -rw-r-----\n> -rw-r--r--\n> -rwxr-xr-x\n> \n> > git was made for tracking source code, not 640 files.\n> \n> On the sneakernet no public patches would be sent, and the\n> administrator would remember to make the sensitive .git directories\n> 700. And sure, git should enforce umask or no set-uid or whatever when\n> doing a checkout etc. The deluxe edition of git could even print a\n> warning: \"you are trying to track a 640 file but your .git permissions\n> are less restrictive.\" However I recommend no premium or deluxe\n> editions for now.\n\nThe fundamental issue is that git is intended to support development, \nwhich is to say that users have to be able to create trees that reflect \nthe content that they intend the project to have, rather than only content \nthat they can represent directly in their working tree. In order to do \ndevelopment on an exim configuration, you may want to be able to set \npermissions and ownership that will only make sense in the production \nenvironment. So it's actually better to have some setup where you've got a \nmetadata file (that you can make arbitrary changes to without any \nparticular hassle) in addition to the content files, and a script for \nputting the files in place with the metadata applied on the live server.\n\nThat is, preserving metadata would allow you to use git as a really \ncomplicated version of tar, but wouldn't give you the advantages of using \ngit.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"97234","messageId":"20081206012913.GA2910@coredump.intra.peff.net","threadId":"16606","inReplyTo":"7vljuuxn66.fsf@gitster.siamese.dyndns.org","subject":"Re: why not preserve file permissions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-06T01:29:14Z","receivedAt":"2008-12-06T01:29:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 05, 2008 at 02:38:41PM -0800, Junio C Hamano wrote:\n\n> Actually in a very early days, git used to record the full (mode & 0777)\n> for blobs.\n> \n> Once people started using git, everybody realized that it had a very\n> unpleasant side effect that the resulting tree depended on user's umasks,\n\nNote, of course that \"everybody\" in your sentence is \"everybody who was\nusing git as a source control mechanism.\" I think as git has grown,\npeople have wanted to use it to version other things, such as dot files\nin their home directory or the contents of /etc, two situations where\nfile metadata might be of as much interest as the file content.\n\nAnd I don't see a real problem in a config switch or two to handle a\nvastly different workflow like that, if it can be done with minimal\nintrusion. For example, now we throw away most of the mode bits; it\nwould probably only be a few lines of code difference to keep those mode\nbits, people who turned on that config option would presumably know what\nthey are doing, and performance for the usual workflow would be\nunaffected.\n\n_But_ I think people who ask for just permission bits aren't really\nthinking things through. Those bits are only one part of the metadata.\nThere's file owner and group. There are timestamps. There are\nnon-regular files with their own associated metadata (like major/minor\ndevice numbers). There are extended attributes, which covers things like\nACLs (and I don't even know if there's a standard representation that\ncan cover the ACLs for all platforms we support).\n\nAnd those things _aren't_ as easy as flipping a config switch. They mean\nchanges to the fundamental data structures of git, and all of the pain\nthat entails: a lot of code, interoperability annoyances, and probably\nperformance impacts for unrelated workflows.\n\nSo I am sympathetic to somebody who, after thinking it through, has a\nuse case that just requires tracking permissions bits and wants a config\noption for git to do that. But the commonly given examples seem much\nbetter served by a _full_ metadata solution that lives on top of git,\nlike metastore. I haven't seen a compelling argument for just handling\npermission bits.\n\n-Peff\n"}]}