{"thread":{"id":"6323","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","startedAt":"2006-12-10T13:40:01Z","lastAt":"2007-01-12T00:55:46Z","messageCount":34,"participants":["David Lang","Shawn O. Pearce","Johannes Schindelin","Josef Weidendorfer","Kyle Moffett","Steven Grimm","Andreas Ericsson","Jakub Narebski","Nikolai Weibull","Daniel Barkalow","Andy Parkins","Junio C Hamano","Jeff Garzik","Santi Béjar","Martin Langhoff","Chris Riddoch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294198","messageId":"787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com","threadId":"6323","inReplyTo":null,"subject":"Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2006-12-10T13:40:01Z","receivedAt":"2006-12-10T13:40:01Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"I've recently become somewhat interested in the idea of using GIT to \nstore the contents of various folders in /etc. However after a bit \nof playing with this, I discovered that GIT doesn't actually preserve \nall permission bits since that would cause problems with the more \ntraditional software development model. I'm curious if anyone has \ndone this before; and if so, how they went about handling the \npermissions and ownership issues.\n\nI spent a little time looking over how GIT stores and compares \npermission bits; trying to figure out if it's possible to patch in a \nnew configuration variable or two; say \"preserve_all_perms\" and \n\"preserve_owner\", or maybe even \"save_acls\". It looks like standard \npermission preservation is fairly basic; you would just need to patch \na few routines which alter the permissions read in from disk or \ncompare them with ones from the database. On the other hand, it \nwould appear that preserving ownership or full POSIX ACLs might be a \nbit of a challenge.\n\nThanks for your insight and advice!\n\nCheers,\nKyle Moffett\n"},{"id":"298413","messageId":"457C1E8E.4080407@garzik.org","threadId":"6323","inReplyTo":"787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2006-12-10T14:49:50Z","receivedAt":"2006-12-10T14:49:50Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Kyle Moffett wrote:\n> I've recently become somewhat interested in the idea of using GIT to \n> store the contents of various folders in /etc. However after a bit of \n> playing with this, I discovered that GIT doesn't actually preserve all \n> permission bits since that would cause problems with the more \n> traditional software development model. I'm curious if anyone has done \n> this before; and if so, how they went about handling the permissions and \n> ownership issues.\n> \n> I spent a little time looking over how GIT stores and compares \n> permission bits; trying to figure out if it's possible to patch in a new \n> configuration variable or two; say \"preserve_all_perms\" and \n> \"preserve_owner\", or maybe even \"save_acls\". It looks like standard \n> permission preservation is fairly basic; you would just need to patch a \n> few routines which alter the permissions read in from disk or compare \n> them with ones from the database. On the other hand, it would appear \n> that preserving ownership or full POSIX ACLs might be a bit of a challenge.\n\nIt's a great idea, something I would like to do, and something I've \nsuggested before. You could dig through the mailing list archives, if \nyou're motivated.\n\nI actively use git to version, store and distribute an exim mail \nconfiguration across six servers. So far my solution has been a 'fix \nperms' script, or using the file perm checking capabilities of cfengine.\n\nBut it would be a lot better if git natively cared about ownership and \npermissions (presumably via an option).\n\n\tJeff\n\n\n"},{"id":"297035","messageId":"8aa486160612100706y92bc722n93374e394fc58005@mail.gmail.com","threadId":"6323","inReplyTo":"787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-12-10T15:06:14Z","receivedAt":"2006-12-10T15:06:14Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 12/10/06, Kyle Moffett wrote:\n> I've recently become somewhat interested in the idea of using GIT to\n> store the contents of various folders in /etc. However after a bit\n> of playing with this, I discovered that GIT doesn't actually preserve\n> all permission bits since that would cause problems with the more\n> traditional software development model. I'm curious if anyone has\n> done this before; and if so, how they went about handling the\n> permissions and ownership issues.\n>\n> I spent a little time looking over how GIT stores and compares\n> permission bits; trying to figure out if it's possible to patch in a\n> new configuration variable or two; say \"preserve_all_perms\" and\n> \"preserve_owner\", or maybe even \"save_acls\". It looks like standard\n> permission preservation is fairly basic; you would just need to patch\n> a few routines which alter the permissions read in from disk or\n> compare them with ones from the database. On the other hand, it\n> would appear that preserving ownership or full POSIX ACLs might be a\n> bit of a challenge.\n>\n> Thanks for your insight and advice!\n\nI have not used it, but you could try:\n\nhttp://www.isisetup.ch/\n\nthat uses git as a backend.\n\n"},{"id":"297349","messageId":"elh91b$v6r$1@sea.gmane.org","threadId":"6323","inReplyTo":"457C1E8E.4080407@garzik.org","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T15:30:00Z","receivedAt":"2006-12-10T15:30:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff Garzik wrote:\n\n> Kyle Moffett wrote:\n>>\n>> I've recently become somewhat interested in the idea of using GIT to \n>> store the contents of various folders in /etc. However after a bit of \n>> playing with this, I discovered that GIT doesn't actually preserve all \n>> permission bits since that would cause problems with the more \n>> traditional software development model. I'm curious if anyone has done \n>> this before; and if so, how they went about handling the permissions and \n>> ownership issues.\n>> \n>> I spent a little time looking over how GIT stores and compares \n>> permission bits; trying to figure out if it's possible to patch in a new \n>> configuration variable or two; say \"preserve_all_perms\" and \n>> \"preserve_owner\", or maybe even \"save_acls\". It looks like standard \n>> permission preservation is fairly basic; you would just need to patch a \n>> few routines which alter the permissions read in from disk or compare \n>> them with ones from the database. On the other hand, it would appear \n>> that preserving ownership or full POSIX ACLs might be a bit of a challenge.\n> \n> It's a great idea, something I would like to do, and something I've \n> suggested before. You could dig through the mailing list archives, if \n> you're motivated.\n> \n> I actively use git to version, store and distribute an exim mail \n> configuration across six servers. So far my solution has been a 'fix \n> perms' script, or using the file perm checking capabilities of cfengine.\n\nFix perms' script used on a checkout hook is a best idea I think.\n \n> But it would be a lot better if git natively cared about ownership and \n> permissions (presumably via an option).\n\nThere is currently no place for ownership and extended attributes in\nthe tree object; and even full POSIX permissions might be challenge\nbecause for example currently unused 'is socket' permission bit is\nused for experimental commit-in-tree submodule support. And given Linus\nstance that git is \"content tracker\"...\n\nIn the loooong thread \"VCS comparison table\" there was some talk\nabout using git (or any SCM) to manage /etc. Check out:\n\n * Message-ID: \n http://permalink.gmane.org/gmane.comp.version-control.git/29765\n * Message-ID: <20061023051932.GA8625@evofed.localdomain>\n http://marc.theaimsgroup.com/?i=<20061023051932.GA8625@evofed.localdomain>\n\n(and other messages in this subthread).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297998","messageId":"28E2300C-8F7A-406F-8FDA-F8786AE95B40@mac.com","threadId":"6323","inReplyTo":"8aa486160612100706y92bc722n93374e394fc58005@mail.gmail.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2006-12-10T17:46:51Z","receivedAt":"2006-12-10T17:46:51Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"> On 12/10/06, Kyle Moffett wrote:\n>> I've recently become somewhat interested in the idea of using GIT \n>> to store the contents of various folders in /etc. However after a \n>> bit of playing with this, I discovered that GIT doesn't actually \n>> preserve all permission bits since that would cause problems with \n>> the more traditional software development model. I'm curious if \n>> anyone has done this before; and if so, how they went about \n>> handling the permissions and ownership issues.\n>>\n>> I spent a little time looking over how GIT stores and compares \n>> permission bits; trying to figure out if it's possible to patch in \n>> a new configuration variable or two; say \"preserve_all_perms\" and \n>> \"preserve_owner\", or maybe even \"save_acls\". It looks like \n>> standard permission preservation is fairly basic; you would just \n>> need to patch a few routines which alter the permissions read in \n>> from disk or compare them with ones from the database. On the \n>> other hand, it would appear that preserving ownership or full \n>> POSIX ACLs might be a bit of a challenge.\n\nOn Dec 10, 2006, at 10:06:14, Santi Béjar wrote:\n> I have not used it, but you could try:\n>\n> http://www.isisetup.ch/\n>\n> that uses git as a backend.\n\nWow, umm, that's actually really interesting for me, given that I'm \nmost interested in these sorts of things on Debian. I can't find \nmuch documentation on their site; the tools look vaguely immature but \nI haven't really had much time to look at it yet.\n\nOn Dec 10, 2006, at 09:49:50, Jeff Garzik wrote:\n> It's a great idea, something I would like to do, and something I've \n> suggested before. You could dig through the mailing list archives, \n> if you're motivated.\n\nI have been digging through the archives; I was just holding out hope \nthat somebody else on the list had already halfway beat me to the \npunch. Guess not :-D\n\n> I actively use git to version, store and distribute an exim mail \n> configuration across six servers. So far my solution has been a \n> 'fix perms' script, or using the file perm checking capabilities of \n> cfengine.\n>\n> But it would be a lot better if git natively cared about ownership \n> and permissions (presumably via an option).\n\nI was thinking about a standard config option in the GIT config file, \nthat way users could have a personal default and repositories could \nspecify it locally.\n\nI started tinkering but quickly discovered that permissions handling \nin general in GIT seems to be a mess; there's about 4 different tiers \nwhere permissions data is manipulated in various formats. Some \nplaces use network-endian 16-bit values, there's a couple functions \nwhich do different truncations to 644 or 755 format. There are 2 \nfunctions which canonicalize the file mode based on symlink or \ndirectory status, each in subtly different ways.\n\nI'm slowly sorting through things but if I could get a few pointers \nfrom someone intimately familiar with the code that would be most \nappreciated: I'd like to try to add new entries to tree objects \nwhich older versions of GIT would ignore but which newer versions of \nGIT would use to store ACL or extended-attribute data.\n\nThe simplest solution which admittedly breaks the ability of older \nGITs to read the data from a file with attributes (ignoring the ext- \nattrs themselves) is to create a new \"file-with-extended-attributes\" \nobject which contains a binary concatenation (with length bytes and \nattribute names and such) of the file and its extended attributes. \nThat breaks the old GIT assumption that permission and security data \nis part of the directory not the file, but it's more in-line with the \nway extended attributes are attached to the inodes in the filesystem \n(although that doesn't really matter IMO).\n\nAlternatively I might be able to add a new entry to each tree object \nwith invalid extended file mods bits (IE: Neither a directory, a \nfile, nor a symlink), or perhaps an entry with an empty name, which \npoints to a new \"extended attribute table\". That table could either \nmap from (entry, attribute) => (data) or from (entry) => \n((attribute,data),(attribute,data),[...]), depending on which would \nbe more efficient. It's essential that the overhead for non-ext-attr \nrepositories is O(1) and ideally the overhead for a bunch of files \nwith the same ext-attr is O(size-of-ext-attr) + O(number-of-files- \nwith-that-attr), although that may vary depending on implementation.\n\nAdvice, opinions, problems, and \"this-has-no-chance-of-ever-even- \nremotely-working\" are all useful and welcome!\n\nCheers,\nKyle Moffett\n"},{"id":"296673","messageId":"A52817B6-0265-4164-8E5D-334AF92DC267@mac.com","threadId":"6323","inReplyTo":"elh91b$v6r$1@sea.gmane.org","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2006-12-10T18:10:04Z","receivedAt":"2006-12-10T18:10:04Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:\n> Jeff Garzik wrote:\n>> I actively use git to version, store and distribute an exim mail \n>> configuration across six servers. So far my solution has been a \n>> 'fix perms' script, or using the file perm checking capabilities \n>> of cfengine.\n>\n> Fix perms' script used on a checkout hook is a best idea I think.\n\nHmm, unfortunately that has problems with security-related race \nconditions when used directly for /etc. Think about what happens \nwith \"/etc/shadow\" in that case, for example. (/etc/.git is of \ncourse 0700) I'm sure there are others where non-root daemons get \nunhappy when they get an inotify event and their config files have \nsuddenly become root:root:0600. I also want to be able to \"cd /etc \n&& git status\" to see what changed after running \"apt-get update\" or \nmaybe fiddling in SWAT or webmin, so a makefile which installs into / \netc won't quite solve it either. It would also be nice to see when \nthings change the permissions on files in /etc, or even bind-mount an \nappend-only volume over /etc/.git/objects to provide additional data \nsecurity.\n\n>> But it would be a lot better if git natively cared about ownership \n>> and permissions (presumably via an option).\n>\n> There is currently no place for ownership and extended attributes \n> in the tree object; and even full POSIX permissions might be \n> challenge because for example currently unused 'is socket' \n> permission bit is used for experimental commit-in-tree submodule \n> support.\n\nWhat about doing something crazy like \"is socket\" && \"is directory\" \n&& \"is symlink\"? Or something else that old GIT versions would \nignore and new GIT versions could do something useful with? Perhaps \nlike I mentioned in an earlier email, the new data could be stored as \npart of a modified \"file\" object. Alternatively could a directory \nhave a file named with an empty string with bogus mode bits which \npoints to an extended-attributes-tree object?\n\n> And given Linus stance that git is \"content tracker\"...\n\nExtended attributes are content too! This includes things like \nicons, security labels (Think unclassified/confidential/secret/top- \nsecret/etc), ACLs, summaries, and other metadata. Content tracker \npurists could also just ignore the new default-off config options and \nbe perfectly happy with status-quo. :-D\n\n> In the loooong thread \"VCS comparison table\" there was some talk \n> about using git (or any SCM) to manage /etc. Check out:\n>\n> * Message-ID: \n> http://permalink.gmane.org/gmane.comp.version-control.git/29765\n> * Message-ID: <20061023051932.GA8625@evofed.localdomain>\n> http://marc.theaimsgroup.com/? \n> i=<20061023051932.GA8625@evofed.localdomain>\n>\n> (and other messages in this subthread).\n\nI have, and while it's interesting material that thread produced no \nreal patches :-D. I'd like to introduce some new config options to \ncontrol the new code: \"preserve_full_perms\", \"preserve_posix_acls\", \n\"preserve_security_labels\", and \"preserve_user_xattrs\" which default \nto false but when set modify GIT's behavior to store, retrieve, and \ncompare additional data.\n\nIf you have any suggestions on how to store the data such that old \nGIT ignores it I'm all ears :-D.\n\nCheers,\nKyle Moffett\n"},{"id":"298586","messageId":"elhidr$tr3$1@sea.gmane.org","threadId":"6323","inReplyTo":"28E2300C-8F7A-406F-8FDA-F8786AE95B40@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T18:10:16Z","receivedAt":"2006-12-10T18:10:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kyle Moffett wrote:\n\n> The simplest solution which admittedly breaks the ability of older  \n> GITs to read the data from a file with attributes (ignoring the ext- \n> attrs themselves) is to create a new \"file-with-extended-attributes\"  \n> object which contains a binary concatenation (with length bytes and  \n> attribute names and such) of the file and its extended attributes.   \n> That breaks the old GIT assumption that permission and security data  \n> is part of the directory not the file, but it's more in-line with the  \n> way extended attributes are attached to the inodes in the filesystem  \n> (although that doesn't really matter IMO).\n\nThis contradict git philosophy of \"tracking contents\".\n\n> Alternatively I might be able to add a new entry to each tree object  \n> with invalid extended file mods bits (IE: Neither a directory, a  \n> file, nor a symlink), or perhaps an entry with an empty name, which  \n> points to a new \"extended attribute table\".  That table could either  \n> map from (entry, attribute) => (data) or from (entry) =>  \n> ((attribute,data),(attribute,data),[...]), depending on which would  \n> be more efficient.  It's essential that the overhead for non-ext-attr  \n> repositories is O(1) and ideally the overhead for a bunch of files  \n> with the same ext-attr is O(size-of-ext-attr) + O(number-of-files- \n> with-that-attr), although that may vary depending on implementation.\n\nWouldn't it be better to add another field in the tree object, that\ninstead of storing \"(filemode, link to contents, name)\" it would\nstore \"(filemode, link to extended attributes, link to contents, name)\"\nwhere \"filemode\" is mode of a file of which git uses only a few bits\n(is a directory, is a symlink, is a file, is a executable file),\nand \"link to\" is sha1 of appropriate blob (or tree) object? Extended\nattributes could be stored in new type of object, or just in blob\nobject. Well, you'd have to extend index in similar way (and add\na way to store extended attributes for directories in index; nowit only\nstores info about files).\n\nThis of course breaks backwards compatibility...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294858","messageId":"elhit4$tr3$2@sea.gmane.org","threadId":"6323","inReplyTo":"A52817B6-0265-4164-8E5D-334AF92DC267@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T18:18:26Z","receivedAt":"2006-12-10T18:18:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kyle Moffett wrote:\n\n> On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:\n>> Jeff Garzik wrote:\n>>>\n>>> I actively use git to version, store and distribute an exim mail \n>>> configuration across six servers. So far my solution has been a \n>>> 'fix perms' script, or using the file perm checking capabilities \n>>> of cfengine.\n>>\n>> Fix perms' script used on a checkout hook is a best idea I think.\n> \n> Hmm, unfortunately that has problems with security-related race \n> conditions when used directly for /etc. Think about what happens \n> with \"/etc/shadow\" in that case, for example. (/etc/.git is of \n> course 0700) I'm sure there are others where non-root daemons get \n> unhappy when they get an inotify event and their config files have \n> suddenly become root:root:0600. I also want to be able to \"cd /etc \n> && git status\" to see what changed after running \"apt-get update\" or \n> maybe fiddling in SWAT or webmin, so a makefile which installs into / \n> etc won't quite solve it either. It would also be nice to see when \n> things change the permissions on files in /etc, or even bind-mount an \n> append-only volume over /etc/.git/objects to provide additional data \n> security.\n\nThe idea is to not store /etc in git directly, but use import/export\nscripts, which for example saves permissions and ownership in some\nfile also tracked by git on import, and restores correct permissions\non export. That is what I remember from this discussion. This of course\nmeans that you would have to write your own porcelain...\n\nWhat about mentioned in other email IsiSetup?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294784","messageId":"200612101926.33307.jnareb@gmail.com","threadId":"6323","inReplyTo":"A52817B6-0265-4164-8E5D-334AF92DC267@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-10T18:26:32Z","receivedAt":"2006-12-10T18:26:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Kyle Moffett wrote:\n> On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:\n>> Jeff Garzik wrote:\n>>>\n>>> I actively use git to version, store and distribute an exim mail  \n>>> configuration across six servers.  So far my solution has been a  \n>>> 'fix perms' script, or using the file perm checking capabilities  \n>>> of cfengine.\n>>\n>> Fix perms' script used on a checkout hook is a best idea I think.\n> \n> Hmm, unfortunately that has problems with security-related race  \n> conditions when used directly for /etc.  Think about what happens  \n> with \"/etc/shadow\" in that case, for example.  (/etc/.git is of  \n> course 0700)  I'm sure there are others where non-root daemons get  \n> unhappy when they get an inotify event and their config files have  \n> suddenly become root:root:0600.  I also want to be able to \"cd /etc  \n> && git status\" to see what changed after running \"apt-get update\" or  \n> maybe fiddling in SWAT or webmin, so a makefile which installs into / \n> etc won't quite solve it either.  It would also be nice to see when  \n> things change the permissions on files in /etc, or even bind-mount an  \n> append-only volume over /etc/.git/objects to provide additional data  \n> security.\n\nThe idea is to not store /etc in git directly, but use import/export\nscripts, which for example saves permissions and ownership in some\nfile also tracked by git on import, and restores correct permissions\non export. That is what I remember from this discussion. This of course\nmeans that you would have to write your own porcelain...\n\nWhat about mentioned in other email IsiSetup?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"295433","messageId":"19476830-E30A-42B7-AD9B-4C417D830C8E@mac.com","threadId":"6323","inReplyTo":"200612101926.33307.jnareb@gmail.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2006-12-10T18:35:17Z","receivedAt":"2006-12-10T18:35:17Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Dec 10, 2006, at 13:26:32, Jakub Narebski wrote:\n> The idea is to not store /etc in git directly, but use import/ \n> export scripts, which for example saves permissions and ownership \n> in some file also tracked by git on import, and restores correct \n> permissions on export. That is what I remember from this \n> discussion. This of course means that you would have to write your \n> own porcelain...\n>\n> What about mentioned in other email IsiSetup?\n\nThe real problem I have with that is you literally have to duplicate \nall sorts of functionality. I want to run \"foo-status\" in /etc and \nget something useful, but if /etc is not a git directory in and of \nitself then you have to duplicate most of \"git-status\" anyways. And \nthe same applies to all the other commands. From what I can see of \nIsiSetup the tools for checking out, merging, modifying, cloning, etc \nare all much more limited and immature than the ones available \nthrough GIT/cogito, and I would be loathe to discard all that extra \nfunctionality and duplicate a few thousand lines of code in the name \nof \"concept purity\".\n\nGIT already has _some_ idea about file permissions, it just discards \nmost of the data before writing to disk. Of course, adding POSIX \nACLs and user-extended-attributes requires a new data format, but \nthose are very similar to filesystem permissions; they differ only in \namount of data stored, not in purpose.\n\nImport/export scripts literally require wrapping every single GIT \ncommand with a script that changes directory a few times, reads from \na different checked-out tree, and permutes some extended-attribute \ndata slightly before storing it in the underlying GIT tree. Even \nwithout adding any new functionality whatsoever that doubles the \namount of code just for finding your repository and checking command- \nline arguments, and that's a crazy trade-off to make in any situation.\n\nCheers,\nKyle Moffett\n"},{"id":"294735","messageId":"457D3573.2010001@op5.se","threadId":"6323","inReplyTo":"19476830-E30A-42B7-AD9B-4C417D830C8E@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-11T10:39:47Z","receivedAt":"2006-12-11T10:39:47Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Kyle Moffett wrote:\n> On Dec 10, 2006, at 13:26:32, Jakub Narebski wrote:\n>> The idea is to not store /etc in git directly, but use import/export \n>> scripts, which for example saves permissions and ownership in some \n>> file also tracked by git on import, and restores correct permissions \n>> on export. That is what I remember from this discussion. This of \n>> course means that you would have to write your own porcelain...\n>>\n>> What about mentioned in other email IsiSetup?\n> \n> The real problem I have with that is you literally have to duplicate all \n> sorts of functionality. I want to run \"foo-status\" in /etc and get \n> something useful, but if /etc is not a git directory in and of itself \n> then you have to duplicate most of \"git-status\" anyways.\n\nMake /etc/.git a symlink to where you store your repo and go to the \nother directory when you want to *restore* configuration. The only \"own \nporcelain\" you need to write is a simple program that understands \"save\" \nand \"restore\" (or some such) and tucks away the meta-data in a file \nsomewhere inside the git tree. If you make it in the format\n\noctal-mode path/to/file\n\nyou can even get decently human-readable permission diffs, which will \nmost likely be prettier and easier to read than anything git currently has.\n\n> \n> GIT already has _some_ idea about file permissions, it just discards \n> most of the data before writing to disk. Of course, adding POSIX ACLs\n> and user-extended-attributes requires a new data format, but those are \n> very similar to filesystem permissions; they differ only in amount of \n> data stored, not in purpose.\n> \n\nThe amount of data stored is the issue here. The current implementation \n(which works just fine and does The Right Thing(tm) for code-repos) only \nstores what it has to and uses the spare bits to do other things.\n\n> Import/export scripts literally require wrapping every single GIT \n> command with a script that changes directory a few times, reads from a \n> different checked-out tree, and permutes some extended-attribute data \n> slightly before storing it in the underlying GIT tree. Even without \n> adding any new functionality whatsoever that doubles the amount of code \n> just for finding your repository and checking command-line arguments, \n> and that's a crazy trade-off to make in any situation.\n> \n\nGIT_DIR=/some/where/else/.git git log -p\n\nWhy would you want to read from a different checked-out tree? \nNon-committed data is \"changes\", committed data is \"HEAD\" (or \ncommit-ish) and marked data is \"index\". I see no reason what so ever for \na second checked-out tree.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294882","messageId":"dbfc82860612110250g73708f7al88c1b50acb2c0dcd@mail.gmail.com","threadId":"6323","inReplyTo":"787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2006-12-11T10:50:59Z","receivedAt":"2006-12-11T10:50:59Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 12/10/06, Kyle Moffett wrote:\n> I've recently become somewhat interested in the idea of using GIT to\n> store the contents of various folders in /etc. However after a bit\n> of playing with this, I discovered that GIT doesn't actually preserve\n> all permission bits since that would cause problems with the more\n> traditional software development model. I'm curious if anyone has\n> done this before; and if so, how they went about handling the\n> permissions and ownership issues.\n\nI keep the files I want to track in a separate folder that I track\nwith Git and use a Makefile for updating /etc. I basically have a\nrule for checking for differences between the tracked folder and /etc\nand a rule for installing changed files (with the correct\npermissions). It works, but it does require some \"Makefile magic\" to\nwork right (or the way /I/ want it anyway).\n\n"},{"id":"297001","messageId":"457D390C.6020605@garzik.org","threadId":"6323","inReplyTo":"457D3573.2010001@op5.se","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2006-12-11T10:55:08Z","receivedAt":"2006-12-11T10:55:08Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Another option is to have a process that stores your configs in git, and \nscript an export from git to rpm|deb. Packaging systems make it even \neasier to go between config versions.\n\n\tJeff\n\n\n"},{"id":"294176","messageId":"200612111313.34292.Josef.Weidendorfer@gmx.de","threadId":"6323","inReplyTo":"457D3573.2010001@op5.se","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-11T12:13:34Z","receivedAt":"2006-12-11T12:13:34Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 11 December 2006 11:39, Andreas Ericsson wrote:\n> > Import/export scripts literally require wrapping every single GIT \n> > command with a script that changes directory a few times, reads from a \n> > different checked-out tree, and permutes some extended-attribute data \n> > slightly before storing it in the underlying GIT tree. Even without \n> > adding any new functionality whatsoever that doubles the amount of code \n> > just for finding your repository and checking command-line arguments, \n> > and that's a crazy trade-off to make in any situation.\n> > \n> \n> GIT_DIR=/some/where/else/.git git log -p\n\nDoing this everytime you want to run a git command *is* a lot of time\nwasted for typing.\n\nThe .gitlink proposal would come in handy here: you have a simple\nfile instead of .git/, which links to the real repository.\n\n"},{"id":"297034","messageId":"Pine.LNX.4.63.0612111432520.2807@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6323","inReplyTo":"200612111313.34292.Josef.Weidendorfer@gmx.de","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-11T13:33:35Z","receivedAt":"2006-12-11T13:33:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 11 Dec 2006, Josef Weidendorfer wrote:\n\n> On Monday 11 December 2006 11:39, Andreas Ericsson wrote:\n> > > Import/export scripts literally require wrapping every single GIT \n> > > command with a script that changes directory a few times, reads from a \n> > > different checked-out tree, and permutes some extended-attribute data \n> > > slightly before storing it in the underlying GIT tree. Even without \n> > > adding any new functionality whatsoever that doubles the amount of code \n> > > just for finding your repository and checking command-line arguments, \n> > > and that's a crazy trade-off to make in any situation.\n> > > \n> > \n> > GIT_DIR=/some/where/else/.git git log -p\n> \n> Doing this everytime you want to run a git command *is* a lot of time\n> wasted for typing.\n> \n> The .gitlink proposal would come in handy here: you have a simple\n> file instead of .git/, which links to the real repository.\n\nI beg your pardon; I'm just joining in. Why is a symbolic link for .git \ninacceptable?\n\nCiao,\nDscho\n"},{"id":"294306","messageId":"200612111607.06046.Josef.Weidendorfer@gmx.de","threadId":"6323","inReplyTo":"Pine.LNX.4.63.0612111432520.2807@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-11T15:07:05Z","receivedAt":"2006-12-11T15:07:05Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 11 December 2006 14:33, Johannes Schindelin wrote:\n> On Mon, 11 Dec 2006, Josef Weidendorfer wrote:\n> \n> > On Monday 11 December 2006 11:39, Andreas Ericsson wrote:\n> > > > Import/export scripts literally require wrapping every single GIT \n> > > > command with a script that changes directory a few times, reads from a \n> > > > different checked-out tree, and permutes some extended-attribute data \n> > > > slightly before storing it in the underlying GIT tree. Even without \n> > > > adding any new functionality whatsoever that doubles the amount of code \n> > > > just for finding your repository and checking command-line arguments, \n> > > > and that's a crazy trade-off to make in any situation.\n> > > > \n> > > \n> > > GIT_DIR=/some/where/else/.git git log -p\n> > \n> > Doing this everytime you want to run a git command *is* a lot of time\n> > wasted for typing.\n> > \n> > The .gitlink proposal would come in handy here: you have a simple\n> > file instead of .git/, which links to the real repository.\n> \n> I beg your pardon; I'm just joining in. Why is a symbolic link for .git \n> inacceptable?\n\nYou are totally right.\n\nThe .gitlink thing is tailored to allow submodule support later. It includes\nsome smart searching for the git repository to allow moving the checkout in\nsome limits without breaking the link to the repository.\n\nAside from this, the proposal is more flexible in that you can specify not\nonly GIT_DIR (or the GIT_DIR_HINT to trigger smart search), but also\nGIT_INDEX_FILE and GIT_HEAD_FILE, which allows different checkouts\n(with different index state and HEAD) for the same repo easily.\n\nWhich is not needed in this case.\nSo, sorry for the noise ;-)\n\n"},{"id":"297897","messageId":"Pine.LNX.4.64.0612111837210.20138@iabervon.org","threadId":"6323","inReplyTo":"787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-12-12T03:45:25Z","receivedAt":"2006-12-12T03:45:25Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 10 Dec 2006, Kyle Moffett wrote:\n\n> I've recently become somewhat interested in the idea of using GIT to store the\n> contents of various folders in /etc. However after a bit of playing with\n> this, I discovered that GIT doesn't actually preserve all permission bits\n> since that would cause problems with the more traditional software development\n> model. I'm curious if anyone has done this before; and if so, how they went\n> about handling the permissions and ownership issues.\n> \n> I spent a little time looking over how GIT stores and compares permission\n> bits; trying to figure out if it's possible to patch in a new configuration\n> variable or two; say \"preserve_all_perms\" and \"preserve_owner\", or maybe even\n> \"save_acls\". It looks like standard permission preservation is fairly basic;\n> you would just need to patch a few routines which alter the permissions read\n> in from disk or compare them with ones from the database. On the other hand,\n> it would appear that preserving ownership or full POSIX ACLs might be a bit of\n> a challenge.\n\nThe first thing you'd want to do is correct the fact that the index \ndoesn't keep full permissions. We decided long ago that we don't want to \ntrack more than 0100, but we're discarding the rest between the filesystem \nand the index, rather than between the index and the tree. (This is weird \nof us, since we keep gid and uid in the index, as changedness heuristics, \nbut don't keep permissions; of course, we'd have to apply umask to the \nindex when we check it out to sync what we expect to be there with what \nhas actually been created.)\n\nI think that would be the only change needed to the index and \nindex/working directory connection, although it might be necessary to \nsupport longer values for uid/gid/etc, since they'd be important data now.\n\nNote that git only stores content, not incidental information. But a lot \nof information which is incidental in a source tree is content in /etc. \nThis implies that /etc and working/linux-2.6 are fundamentally different \nsorts of things, because different aspects of them are content.\n\nI'd suggest a new object type for a directory with permissions, ACLs, and \nso forth. It should probably use symbolic owner and group, too. My guess \nis that you'll want to use \"commit\"s, the new object type, and \"blob\"s. \nEverything that uses trees would need to have a version that uses the new \ntype. But I think that you generally want different behavior anyway, so \nthat's not a major issue.\n\n\t-Daniel\n"},{"id":"296531","messageId":"8900B938-1360-4A67-AB15-C9E84255107B@mac.com","threadId":"6323","inReplyTo":"Pine.LNX.4.64.0612111837210.20138@iabervon.org","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2006-12-12T13:49:26Z","receivedAt":"2006-12-12T13:49:26Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Dec 11, 2006, at 22:45:25, Daniel Barkalow wrote:\n> The first thing you'd want to do is correct the fact that the index \n> doesn't keep full permissions. We decided long ago that we don't \n> want to track more than 0100, but we're discarding the rest between \n> the filesystem and the index, rather than between the index and the \n> tree. (This is weird of us, since we keep gid and uid in the index, \n> as changedness heuristics, but don't keep permissions; of course, \n> we'd have to apply umask to the index when we check it out to sync \n> what we expect to be there with what has actually been created.)\n>\n> I think that would be the only change needed to the index and index/ \n> working directory connection, although it might be necessary to \n> support longer values for uid/gid/etc, since they'd be important \n> data now.\n\nHmm, ok. It would seem to be a reasonable requirement that if you \nwant to change any of the \"preserve_*_attributes\" config options you \nneed to blow away and recreate your index, no? I would probably \nchange the underlying index format pretty completely and stick a new \nversion tag inside it.\n\n> Note that git only stores content, not incidental information. But \n> a lot of information which is incidental in a source tree is \n> content in /etc. This implies that /etc and working/linux-2.6 are \n> fundamentally different sorts of things, because different aspects \n> of them are content.\n\nAhh, I hadn't thought of it that way before but that makes a lot of \nsense. Thanks!\n\n> I'd suggest a new object type for a directory with permissions, \n> ACLs, and so forth. It should probably use symbolic owner and \n> group, too. My guess is that you'll want to use \"commit\"s, the new \n> object type, and \"blob\"s. Everything that uses trees would need to \n> have a version that uses the new type. But I think that you \n> generally want different behavior anyway, so that's not a major issue.\n\nOk, seems straightforward enough. One other thing that crossed my \nmind was figuring out how to handle hardlinks. The simplest solution \nwould be to add an extra layer of indirection between the \"file \ninode\" and the \"file data\". Instead of your directory pointing to a \n\"file-data\" blob and \"file-attributes\" object, it would point to an \n\"file-inode\" object with embedded attribute data and a pointer to the \nfile contents blob.\n\nI remember reading some discussions from the early days of GIT about \nhow that was considered and discarded because the extra overhead \nwouldn't give any real tangible benefit. On the other hand for \nsomething like /etc the added benefits of tracking extended \nattributes and hardlinks might outweigh the cost of a bunch of extra \nobjects in the database. A bit of care with the construction of the \nindex file should make it sufficiently efficient for day-to-day usage.\n\nIf you're interested in some random musings about using GIT concepts \nto version whole filesystems (think checkpointing your disk drive and \ninstantly restoring when you screw up), read on below, otherwise \ndon't bother.\n\nCheers,\nKyle Moffett\n\n\n\nNOTE: This probably belongs in it's own thread but it's such a \nrandom, undeveloped, and off-the-wall concept that I threw it in here \njust for kicks.\n\nCombining extensions like those described above with something like \nthe Ext3 block-allocation, inode-management and journalling code to \nproduce a \"versioned filesystem\". With the exponential growth of \nstorage density over the last several years we've gotten to the point \nwhere we can many many hours of extremely realistic video and audio \non your average small-computer drive. Versioning your home \ndirectory, or even your entire computer, even with fairly steady \nmodifications to multimedia files, installation of software programs, \netc, doesn't seem like such an impossible undertaking anymore.\n\nOne predefined inode would contain a list of tags/heads and their \ncurrent hashes. Mount the filesystem with a \"tag=$TAG\" option to \nspecify the initial tree object used for the root directory (with \nsyscalls to navigate the history). Allocate an inode per-mount to \nrepresent any changes from the last commit.\n\nFor efficiency purposes (no need to revision the entire system when I \ncommit a change in my home directory) add a \"subtree\" object type \nwhich can specify either a particular hash or a symbolic tag/head \nname as a pseudo sub-mountpoint. Trap traversal of the sub- \nmountpoint node to mount the filesystem with \"tag=$SUBTAG\" on the sub- \nmountpoint, expiring it some time after the last traversal.\n\nThe only remaining issue would be properly navigating through the \nhistory, preserving or discarding changes. Since the kernel could \neasily manage copy-on-write semantics for underlying disk blocks you \nwouldn't need a separate \"working copy\" except where it's modified \nfrom the original, and discarding changes is as simple as unlinking \nany files referenced by the per-mount delta inode.\n\nCommitting changes would get tricky, you would need to hot-remap \nmemory-mapped pages read-only while you checksum and store them. The \nnext write attempt would then separate the page from the freshly- \ncommitted on-disk version. Would need a mechanism for applications \nto \"trap\" the commit so they could make databases consistent, with \nthe ability for root or the mountpoint owner to commit without \nwaiting for synchronization. Only needs to synchronize files \nbelonging to the new commit. Merges would be managed from userspace, \nas long as there is a way to browse through objects by hash given \nsufficient permissions.\n\nMake sure it's really easy to make a new atomic commit and/or reset \nto a known state every time the computer is rebooted (whether soft- \nrebooted or via crash/powerkill). With journalling and the write- \nonce nature of GIT it would be trivial to never require an fsck run. \nAlso needs a way to move data between filesystems. Makes LVM largely \nirrelevant; it doesn't matter how many disks you have if they're all \ntreated as a shared storage pool for your GITfs data. Make sure it's \npossible to archive data onto slower disks/media and purge older \ncommits from the archive (missing parent commit references are \ntolerable in many situations). Needs a way to notice hash collisions \nand take action to avoid them.\n\n\n\nCheers,\nKyle Moffett\n"},{"id":"295118","messageId":"200612121553.37499.andyparkins@gmail.com","threadId":"6323","inReplyTo":"8900B938-1360-4A67-AB15-C9E84255107B@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-12T15:53:36Z","receivedAt":"2006-12-12T15:53:36Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2006 December 12 13:49, Kyle Moffett wrote:\n\n> Hmm, ok. It would seem to be a reasonable requirement that if you\n> want to change any of the \"preserve_*_attributes\" config options you\n> need to blow away and recreate your index, no? I would probably\n> change the underlying index format pretty completely and stick a new\n> version tag inside it.\n\nI wonder if git's skill at managing content is the answer? Rather than mess \naround with git's internals, the index, or the object database; how about \nsimply having a pre-commit script that writes out a file that looks like:\n\n-rw-r--r-- andyp andyp CHANGES\n-rw-r--r-- andyp andyp COPYING\n-rw-rw-r-- andyp andyp CREDITS\n-rw-r--r-- andyp andyp Configure\n-rw-rw-r-- andyp andyp Makefile\n-rw-r--r-- andyp andyp README\n\nIf /that/ file were stored in the repository and you had a script that could \nread that file and apply the permissions after a checkout you'd have what you \nwant.\n\nIf the permissions of a file changed but the content didn't, then \nthis \".gitpermissions\" file would have changed content but the file itself \nwould remain the same. If the content changed but not the permissions \nthen \".gitpermissions\" would be untouched.\n\nAssuming that you're allowed to mess with the index in pre-commit (I haven't \nchecked), one half of it can be automatic. I suppose you could also plead \nfor a post-checkout hook to apply those permissions and the whole lot would \nbe transparent.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294276","messageId":"457F31E6.8090701@midwinter.com","threadId":"6323","inReplyTo":"200612121553.37499.andyparkins@gmail.com","subject":"Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-12T22:49:10Z","receivedAt":"2006-12-12T22:49:10Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"This discussion reminds me of a use of git I've had in the back of my \nhead to try out for a while. Right now I'm doing my local snapshot \nbackups using the rsync-with-hard-links scheme \n(http://www.mikerubel.org/computers/rsync_snapshots/ if you're not \nfamiliar with it). This is nice in that the contents of files that don't \nchange are only stored once on the backup disk. But it is less than \noptimal in that a file that changes even a little bit is stored from \nscratch.\n\nWhat would be great for this would be to store each day's backup as a \ngit revision; with a periodic repack, this would be much more \nspace-efficient than the rsync hard links.\n\nThe problem is that while that would give me a very efficient backup \nscheme, the repository would still grow over time. In rsync land, I \nsolve the disk space issue by keeping two weeks' worth of daily \nsnapshots, then six months' worth of weekly snapshots, then two years' \nworth of monthly snapshots; files that change daily have a constant \nnumber of revisions stored in my backups, and older files drop off the \nbackup disk as they age.\n\nGiven that there's no way (or is there?) to delete revisions from the \n*beginning* of a git revision history, right now it seems like the only \napproach that comes close is to give up on the \"daily then weekly then \nmonthly\" thing -- probably fine given the space savings of delta \ncompression -- and periodically make shallow clones of the backup \nrepository that fetch all but the first N revisions; once a shallow \nclone is made, the original gets deleted and the clone is the new backup \nrepo.\n\nBut it would sure be more efficient to be able to \"shallow-ize\" an \nexisting repository. That would be useful for things other than backups, \ntoo, e.g. the recent request for some way to track just the current \nversion of the kernel code rather than its revision history. If there \nwere a shallowize command, you could do something like \"git pull; git \nshallowize --depth 1\" to track the latest revision without keeping the \nhistory locally.\n\nAnyone think that sounds like an interesting thing to explore?\n\n-Steve\n"},{"id":"293917","messageId":"Pine.LNX.4.63.0612122355400.2807@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6323","inReplyTo":"457F31E6.8090701@midwinter.com","subject":"Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-12T22:57:20Z","receivedAt":"2006-12-12T22:57:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Dec 2006, Steven Grimm wrote:\n\n> If there were a shallowize command, you could do something like \"git \n> pull; git shallowize --depth 1\" to track the latest revision without \n> keeping the history locally.\n\nAlmost!\n\n$ git pull --depth 1\n\nThough it needs a server _and_ a client supporting shallow clones, which \nsupport is brewed in \"next\" right now.\n\nCiao,\nDscho\n"},{"id":"296580","messageId":"457F3606.7020805@midwinter.com","threadId":"6323","inReplyTo":"Pine.LNX.4.63.0612122355400.2807@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-12T23:06:46Z","receivedAt":"2006-12-12T23:06:46Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> $ git pull --depth 1\n>\n> Though it needs a server _and_ a client supporting shallow clones, which \n> support is brewed in \"next\" right now.\n> \n\nWill that actually discard old revisions that are already stored locally?\n\n-Steve\n"},{"id":"297504","messageId":"46a038f90612121515l77c77376xd98e148498e889c4@mail.gmail.com","threadId":"6323","inReplyTo":"457F31E6.8090701@midwinter.com","subject":"Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-12-12T23:15:25Z","receivedAt":"2006-12-12T23:15:25Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Steven,\n\nI've been thinking myself of writing a pdumpfs lookalike that uses git\ninternally. Sounds you you've got one already ;-)\n\nIn terms of getting rid of old history, have you considered moving a\ngraft point \"forward\" in time, and running git-repack -a -d? With your\nhistory being (mostly?) linear this could be a workable scheme, but I\ndon't have much practice with using grafts.\n\ncheers,\n\n\n"},{"id":"298590","messageId":"46a038f90612121523p5278fd43mffb90d9d92cd2fde@mail.gmail.com","threadId":"6323","inReplyTo":"46a038f90612121515l77c77376xd98e148498e889c4@mail.gmail.com","subject":"Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-12-12T23:23:07Z","receivedAt":"2006-12-12T23:23:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 12/13/06, Martin Langhoff wrote:\n> I've been thinking myself of writing a pdumpfs lookalike that uses git\n> internally. Sounds you you've got one already ;-)\n\nActually - what I was considering was mixing the \"daily commit\" with\nGITFS ;-) http://www.sfgoth.com/~mitch/linux/gitfs/\n\nare your scripts published anywhere?\n\ncheers,\n\n\n"},{"id":"298594","messageId":"7vfybkof3s.fsf@assigned-by-dhcp.cox.net","threadId":"6323","inReplyTo":"457F31E6.8090701@midwinter.com","subject":"Re: Using git as a general backup mechanism","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-12T23:43:03Z","receivedAt":"2006-12-12T23:43:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> What would be great for this would be to store each day's backup as a\n> git revision; with a periodic repack, this would be much more\n> space-efficient than the rsync hard links.\n>\n> The problem is that while that would give me a very efficient backup\n> scheme, the repository would still grow over time. In rsync land, I\n> solve the disk space issue by keeping two weeks' worth of daily\n> snapshots, then six months' worth of weekly snapshots, then two years'\n> worth of monthly snapshots; files that change daily have a constant\n> number of revisions stored in my backups, and older files drop off the\n> backup disk as they age.\n\nWhy not use N independent branches? I'd illustrate only with\ntwo levels below, but you could:\n\n (0) make a full tree snapshot. Store the commit in 'daily'\n branch as its tip.\n\n (1) A new day comes. Create an empty branch 'daily' if you\n do not already have one. Make a full tree snapshot, and\n create a parentless commit for the day if the 'daily'\n branch did not exist, or make it a child of the 'daily'\n commit from the previous day if the branch existed.\n\n (2) End of week comes. Create an empty branch 'weekly' if you\n do not already have one. Make a full tree snapshot, and\n create a parentless commit for the week if the 'weekly'\n branch did not exist, or make it a child of the 'weekly'\n commit from the last week. Discard 'lastweek' branch if\n you have one, and rename 'daily' branch to 'lastweek'.\n\nAt the end of month, you can rename 'weekly' to 'lastmonth'; if\nyou discard previous 'lastmonth' at this point, you essentially\nmade files older than two months drop off the backup disk. You\ncan add more hierarchy with longer period to extend the scheme\nad infinitum.\n"},{"id":"297731","messageId":"Pine.LNX.4.63.0612130100220.2807@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6323","inReplyTo":"457F3606.7020805@midwinter.com","subject":"Re: Using git as a general backup mechanism (was Re: Using GIT to store /etc)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-13T00:01:39Z","receivedAt":"2006-12-13T00:01:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Dec 2006, Steven Grimm wrote:\n\n> Johannes Schindelin wrote:\n> > $ git pull --depth 1\n> > \n> > Though it needs a server _and_ a client supporting shallow clones, \n> > which support is brewed in \"next\" right now.\n> \n> Will that actually discard old revisions that are already stored \n> locally?\n\nNo. A pull should _never_ lose anything from the repository. However, if \nsome objects become no-longer reachable (and at the moment it looks like \nwe cut of history, even if we should not need to), they can be pruned from \nthe repo.\n\nHth,\nDscho\n"},{"id":"295103","messageId":"Pine.LNX.4.64.0612131156500.20138@iabervon.org","threadId":"6323","inReplyTo":"8900B938-1360-4A67-AB15-C9E84255107B@mac.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-12-13T18:10:01Z","receivedAt":"2006-12-13T18:10:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 12 Dec 2006, Kyle Moffett wrote:\n\n> Hmm, ok. It would seem to be a reasonable requirement that if you want to\n> change any of the \"preserve_*_attributes\" config options you need to blow away\n> and recreate your index, no? I would probably change the underlying index\n> format pretty completely and stick a new version tag inside it.\n\nYou should be able to promote an insufficient-version index to a \nnew-version index that's needs to be refreshed for every entry. (And then \nupdate-index would take care of the necessary rewrite-everything in the \nnormal way). But I suspect that the right thing is to require that the \nrepository be created with a \"commits-include-directories-not-trees\" flag, \nand this means that you always use the extra-detailed index, and the \noptions only affect what information is filtered out in transit between \nthe directory object and the index. Having more information in the index \nis merely a potential waste of space, not a correctness issue (we have \nextra information for trees in the index now, remember); it just means \nthat there are more things that will cause git to reread the file, rather \nthan declaring it unchanged with a stat().\n\nFor that matter, it may be best for the directory objects to record what \ninformation in them is real, and keep the \"what's content\" mask in the \nindex as well. If it changes over the history of a repository, you want to \ncorrectly interpret the historical commits.\n\n> Ok, seems straightforward enough. One other thing that crossed my mind was\n> figuring out how to handle hardlinks. The simplest solution would be to add\n> an extra layer of indirection between the \"file inode\" and the \"file data\".\n> Instead of your directory pointing to a \"file-data\" blob and \"file-attributes\"\n> object, it would point to an \"file-inode\" object with embedded attribute data\n> and a pointer to the file contents blob.\n>\n> I remember reading some discussions from the early days of GIT about how that\n> was considered and discarded because the extra overhead wouldn't give any real\n> tangible benefit. On the other hand for something like /etc the added\n> benefits of tracking extended attributes and hardlinks might outweigh the cost\n> of a bunch of extra objects in the database. A bit of care with the\n> construction of the index file should make it sufficiently efficient for\n> day-to-day usage.\n\nI was thinking this could be internal to the directory object, but you \nprobably want to support hardlinks shared between dentries in different \ndirectory objects, so you're probably right that this makes sense. \n\nAlternatively, you could use a single \"directory\" object for the whole \nstate (including subdirectories), making hardlinks out of the object \nclearly impossible, or you could use some scheme for sharing \nsub-\"directory\" objects that would imply that hardlinks are within an \nobject (the hard part here is finding things when their locations aren't \npredictable by name).\n\n\t-Daniel\n"},{"id":"297765","messageId":"6efbd9b70612132106q4ef2a323se743bfd6378d15d3@mail.gmail.com","threadId":"6323","inReplyTo":"Pine.LNX.4.64.0612131156500.20138@iabervon.org","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Chris Riddoch","fromEmail":"riddochc@gmail.com","sentAt":"2006-12-14T05:06:31Z","receivedAt":"2006-12-14T05:06:31Z","isPatch":false,"sender":{"key":"riddochc@gmail.com","avatar":null},"body":"So, I've been making little repositories for appropriately related\nstuff. For example, I have a repository for my ~/.bashrc,\n~/.bash_profile, ~/.bash_completions/*, and such.\n\nI recall Linus's post in the \"VCS Comparison Table\" thread, and after\nthinking about it, I decided the best thing to do would be to have a\ncouple extra files tracked in the repository, alongside other data.\n\nI use a backup shell script to copy things from my system to the\nrepository, and then I run getfacl on it all to write out all the\ndetails to a 'facl' file in my repository. Then I can make a commit.\n\nThen there's a restore shell script to copy things back to my system,\nand restore ownership and permissions with setfacl.\n\nI store the backup and restore scripts in the repository. Paths are\ncurrently hard-coded. I'm sure there's a more flexible way to do\nthis, though I'd need some means of representing the correspondence\nbetween content in the repository and files in my filesystem.\n\n\nOn 12/13/06, Daniel Barkalow wrote:\n> On Tue, 12 Dec 2006, Kyle Moffett wrote:\n>\n> > Hmm, ok. It would seem to be a reasonable requirement that if you want to\n> > change any of the \"preserve_*_attributes\" config options you need to blow\n> away\n> > and recreate your index, no? I would probably change the underlying index\n> > format pretty completely and stick a new version tag inside it.\n>\n> You should be able to promote an insufficient-version index to a\n> new-version index that's needs to be refreshed for every entry. (And then\n> update-index would take care of the necessary rewrite-everything in the\n> normal way). But I suspect that the right thing is to require that the\n> repository be created with a \"commits-include-directories-not-trees\" flag,\n> and this means that you always use the extra-detailed index, and the\n> options only affect what information is filtered out in transit between\n> the directory object and the index. Having more information in the index\n> is merely a potential waste of space, not a correctness issue (we have\n> extra information for trees in the index now, remember); it just means\n> that there are more things that will cause git to reread the file, rather\n> than declaring it unchanged with a stat().\n>\n> For that matter, it may be best for the directory objects to record what\n> information in them is real, and keep the \"what's content\" mask in the\n> index as well. If it changes over the history of a repository, you want to\n> correctly interpret the historical commits.\n>\n> > Ok, seems straightforward enough. One other thing that crossed my mind\n> was\n> > figuring out how to handle hardlinks. The simplest solution would be to\n> add\n> > an extra layer of indirection between the \"file inode\" and the \"file\n> data\".\n> > Instead of your directory pointing to a \"file-data\" blob and\n> \"file-attributes\"\n> > object, it would point to an \"file-inode\" object with embedded attribute\n> data\n> > and a pointer to the file contents blob.\n> >\n> > I remember reading some discussions from the early days of GIT about how\n> that\n> > was considered and discarded because the extra overhead wouldn't give any\n> real\n> > tangible benefit. On the other hand for something like /etc the added\n> > benefits of tracking extended attributes and hardlinks might outweigh the\n> cost\n> > of a bunch of extra objects in the database. A bit of care with the\n> > construction of the index file should make it sufficiently efficient for\n> > day-to-day usage.\n>\n> I was thinking this could be internal to the directory object, but you\n> probably want to support hardlinks shared between dentries in different\n> directory objects, so you're probably right that this makes sense.\n>\n> Alternatively, you could use a single \"directory\" object for the whole\n> state (including subdirectories), making hardlinks out of the object\n> clearly impossible, or you could use some scheme for sharing\n> sub-\"directory\" objects that would imply that hardlinks are within an\n> object (the hard part here is finding things when their locations aren't\n> predictable by name).\n>\n> \t-Daniel\n> *This .sig left intentionally blank*\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nepistemological humility\n"},{"id":"297167","messageId":"4581DF3E.3070806@midwinter.com","threadId":"6323","inReplyTo":"7vfybkof3s.fsf@assigned-by-dhcp.cox.net","subject":"Re: Using git as a general backup mechanism","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-14T23:33:18Z","receivedAt":"2006-12-14T23:33:18Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> (2) End of week comes. Create an empty branch 'weekly' if you\n> do not already have one. Make a full tree snapshot, and\n> create a parentless commit for the week if the 'weekly'\n> branch did not exist, or make it a child of the 'weekly'\n> commit from the last week. Discard 'lastweek' branch if\n> you have one, and rename 'daily' branch to 'lastweek'.\n\nThat sounds like it'd work, but doesn't it imply that the history of a \ngiven file in the backups is not continuous? That is, an old copy of a \nfile on the \"weekly\" branch doesn't have any kind of ancestor \nrelationship with the same file on the \"daily\" branch? While that's \nobviously no different than the current git-less situation where there's \nno notion of ancestry at all, it'd be neat if this backup scheme could \nactually track long-term changes to individual files.\n\nI wonder if rebasing can get me what I want. Something like:\n\n(1) Make a new branch from the latest daily. Commit a full tree\n snapshot to the new branch. (Each branch has exactly one commit.)\n\n(2) To expire a daily backup, rebase the second-oldest daily branch,\n which will initially be a child of the oldest daily branch, under\n the latest weekly branch instead. Delete the oldest daily branch.\n I believe the right commands here would be:\n\n git-rebase -s recursive -s ours --onto latest-weekly \\\n oldest-daily second-oldest-daily\n git-branch -D oldest-daily\n\n (Not sure about the double \"-s\", but I want it to detect renames\n where possible and never flag any conflicts.)\n\n(3) At the end of the week, instead of expiring the oldest daily\n branch, rename it to indicate that it's now a weekly snapshot.\n (That will implicitly do the first part of step 2, since the\n next daily branch in line will already be a descendant of the\n newly renamed branch.)\n\n Repeat step 2, rebasing against the latest monthly branch,\n to expire the oldest weekly.\n\n(4) To expire an old monthly, rebase the second-oldest monthly branch\n under the initial empty revision, then delete the oldest monthly.\n This is basically step 2 again, but rebasing under a fixed starting\n point.\n\n(5) Run git-prune to expire the objects in the deleted branches, then\n git-repack -a -d to delta-compress everything.\n\nThat's a bit convoluted, admittedly, and probably a perversion of \neverything pure about the branch system, but would it work? The big \nthing I'm not sure about here is whether, after doing my rebase and \ndelete in step 2, the objects from the oldest daily will actually be \nremoved by git-prune. They should be unreachable at that point, I think.\n\n"},{"id":"296608","messageId":"7vwt4uxaj4.fsf@assigned-by-dhcp.cox.net","threadId":"6323","inReplyTo":"4581DF3E.3070806@midwinter.com","subject":"Re: Using git as a general backup mechanism","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T00:33:51Z","receivedAt":"2006-12-15T00:33:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> Junio C Hamano wrote:\n>> (2) End of week comes. Create an empty branch 'weekly' if you\n>> do not already have one. Make a full tree snapshot, and\n>> create a parentless commit for the week if the 'weekly'\n>> branch did not exist, or make it a child of the 'weekly'\n>> commit from the last week. Discard 'lastweek' branch if\n>> you have one, and rename 'daily' branch to 'lastweek'.\n>\n> That sounds like it'd work, but doesn't it imply that the history of a\n> given file in the backups is not continuous? That is, an old copy of a\n> file on the \"weekly\" branch doesn't have any kind of ancestor\n> relationship with the same file on the \"daily\" branch? While that's\n> obviously no different than the current git-less situation where\n> there's no notion of ancestry at all, it'd be neat if this backup\n> scheme could actually track long-term changes to individual files.\n\nYou can keep them connected by rewriting history of bounded\nnumber of commits. When you start a new week, you would make\nthe Monday commit a child of the tip of weekly branch that\nrepresents the latest weekly shapshot. Then on Friday, the\nhistory would show the 5 commits during the week and behind that\nwould be a sequence of commits with one-per-week granularity.\nWhen you rotate the week's daily log out and the commit for\nMonday is based on the weekly history you are going to toss out,\nyou may need to rebase that week's daily log branch.\n\nLet's say your policy is to keep daily log for at least one week\nand enough number of end-of-week weekly logs. Let's say it is\nweek #2 right now.\n\n Aooo... (week #2 daily)\n /|\n ooooooB | (week #1 daily)\n / |\n o--------o---------C (end-of-week weekly log)\n\nThe first commit in this week's daily log (A) would have two\nparents: last commit from daily log of week #1 (B), and the\nlatest commit on the end-of-week weekly log (C). Most likely, B\nand C would have exactly the same tree. That way, you would\nhave at least 7 days of daily log; at the end of this week you\nwould have close to 14 days but \"keeping at least one week\" is\nsatisfied.\n\nWhen starting the 3rd week, you will discard 1st week's log; you\nwould need to rewrite 7 days worth of commits from week #2,\nbecause the first commit of week #2 should now only have one\nparent (C), and you would forget the commit on the last day of\nweek #1 as its parent (B). Which cascades through 7 commits you\nmade during week #2. You are not changing any trees, so this\nshould be quite efficient.\n\nThen the first daily commit of 3rd week would have two parents,\nthe commit at the end of week #2 daily branch (D), and a new\ncommit (E) at the tip of the end-of-week log. Again, D and E\nwould have the identical trees.\n\n o...... (week #3 daily)\n /|\n Aooo..D | (week #2 daily)\n | |\n (week #1 daily - gone) | |\n | |\n o--------o---------C-------E (end-of-week weekly log)\n"},{"id":"31353","messageId":"Pine.LNX.4.63.0701091735490.7747@qynat.qvtvafvgr.pbz","threadId":"6323","inReplyTo":"8aa486160612100706y92bc722n93374e394fc58005@mail.gmail.com","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-01-10T01:39:35Z","receivedAt":"2007-01-10T01:39:35Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"I want to have a tripwire-like system checking the files to make sure that they \nhaven't changed unexpectedly. the program I'm looking at notices inode as well \nas timestamp and content changed.\n\nwhen you checkout a file from git will it re-write/overwrite a file that hasn't \nchanged or will it realize there is no change and leave it as-is?\n\ndoes this answer change if there is a trigger on checkout (to change permissions \nor otherwise manipulate the file)?\n\nDavid Lang\n"},{"id":"31355","messageId":"20070110023031.GC30765@spearce.org","threadId":"6323","inReplyTo":"Pine.LNX.4.63.0701091735490.7747@qynat.qvtvafvgr.pbz","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-10T02:30:31Z","receivedAt":"2007-01-10T02:30:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Lang wrote:\n> I want to have a tripwire-like system checking the files to make sure that \n> they haven't changed unexpectedly. the program I'm looking at notices inode \n> as well as timestamp and content changed.\n> \n> when you checkout a file from git will it re-write/overwrite a file that \n> hasn't changed or will it realize there is no change and leave it as-is?\n\nIf the stat data is current it will leave it as-is. You can force\nthe index to refresh with `git update-index --refresh` or by running\ngit status.\n \n> does this answer change if there is a trigger on checkout (to change \n> permissions or otherwise manipulate the file)?\n\nOnly if the trigger does something in addition, like force overwrite\nfiles. But we don't have a checkout trigger. So there's no trigger.\n\n-- \nShawn.\n"},{"id":"31405","messageId":"Pine.LNX.4.63.0701101027480.10339@qynat.qvtvafvgr.pbz","threadId":"6323","inReplyTo":"20070110023031.GC30765@spearce.org","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-01-10T18:34:31Z","receivedAt":"2007-01-10T18:34:31Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Tue, 9 Jan 2007, Shawn O. Pearce wrote:\n\n> David Lang wrote:\n>> I want to have a tripwire-like system checking the files to make sure that\n>> they haven't changed unexpectedly. the program I'm looking at notices inode\n>> as well as timestamp and content changed.\n>>\n>> when you checkout a file from git will it re-write/overwrite a file that\n>> hasn't changed or will it realize there is no change and leave it as-is?\n>\n> If the stat data is current it will leave it as-is. You can force\n> the index to refresh with `git update-index --refresh` or by running\n> git status.\n\nI was looking at checkout, not checkin so I'm not understanding how the index is \ninvolved here.\n\n>> does this answer change if there is a trigger on checkout (to change\n>> permissions or otherwise manipulate the file)?\n>\n> Only if the trigger does something in addition, like force overwrite\n> files. But we don't have a checkout trigger. So there's no trigger.\n\nwe don't have a checkout trigger? I thought that what Linus had suggested for \npermissions was to have a script triggered on checkin that stored the \npermissions of the files, and a script triggered on checkout that set the \npermissions from the stored file.\n\nif there isn't a checkout trigger how would the permissions ever get set?\n\nin my particular case I'd like to have the checkin run a script that produces a \n'generic' version of each file, and the checkout run a script that converts the \ngeneric version into the host specific version. I already have a script that \ndoes this work (and (ab)uses ssh to propogate the generic version to other hosts \nand create the host specific versions there), but I was interested in useing git \nto add better version control to the generic versions of the files (I currently \nuse RCS on each box to version control the host specific versions)\n\nDavid Lang\n"},{"id":"31529","messageId":"20070112005546.GD23864@spearce.org","threadId":"6323","inReplyTo":"Pine.LNX.4.63.0701101027480.10339@qynat.qvtvafvgr.pbz","subject":"Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-12T00:55:46Z","receivedAt":"2007-01-12T00:55:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Lang wrote:\n> On Tue, 9 Jan 2007, Shawn O. Pearce wrote:\n> >If the stat data is current it will leave it as-is. You can force\n> >the index to refresh with `git update-index --refresh` or by running\n> >git status.\n> \n> I was looking at checkout, not checkin so I'm not understanding how the \n> index is involved here.\n\nDuring checkout we use the index to help us decide if a file needs\nto be updated with new content or can be left as-is. Its a cache of\nwhat version each file is at, and its based on the file stat data\n(dev, inode, modification date, etc.) to tell us if the file has\nbeen modified or was last created by Git. If Git was the one that\nlast modified the file and the version stored in the index matches\nthe version needed during the checkout, the file is left alone.\nBut if anything differs then the file gets overwritten.\n \n> >>does this answer change if there is a trigger on checkout (to change\n> >>permissions or otherwise manipulate the file)?\n> >\n> >Only if the trigger does something in addition, like force overwrite\n> >files. But we don't have a checkout trigger. So there's no trigger.\n> \n> we don't have a checkout trigger?\n\nNo.\n\n> I thought that what Linus had suggested \n> for permissions was to have a script triggered on checkin that stored the \n> permissions of the files, and a script triggered on checkout that set the \n> permissions from the stored file.\n\nYes. It is what he suggested.\n\n> if there isn't a checkout trigger how would the permissions ever get set?\n\nSomeone needs to implement support for a post-checkout trigger. _Then_\na checkout trigger could perform this action.\n\n> in my particular case I'd like to have the checkin run a script that \n> produces a 'generic' version of each file,\n\nYou may be able to do that in the pre-commit hook by updating the index\n\n-- \nShawn.\n"}]}