{"thread":{"id":"9600","subject":"empty directories","startedAt":"2007-08-21T17:14:21Z","lastAt":"2007-08-25T19:35:08Z","messageCount":41,"participants":["Josh England","Sean","Jakub Narebski","Salikh Zakirov","Linus Torvalds","David Kastrup","Junio C Hamano","Johannes Schindelin","Jeff King","Jason Garber","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51181","messageId":"1187716461.5986.71.camel@beauty","threadId":"9600","inReplyTo":null,"subject":"empty directories","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-21T17:14:21Z","receivedAt":"2007-08-21T17:14:21Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"Hi,\n\nGit doesn't seem to allow me to add an empty directory to the index, or\neven nested empty directories.  Is there any way to do this?  What is\nthe reasoning?  I've got a use case where having empty directories in my\ngit repository would be *very* valuable.  Any information and help is\ngreatly appreciated.\n\n-JE\n"},{"id":"51184","messageId":"20070821134030.b763e9d3.seanlkml@sympatico.ca","threadId":"9600","inReplyTo":"1187716461.5986.71.camel@beauty","subject":"Re: empty directories","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-08-21T17:40:30Z","receivedAt":"2007-08-21T17:40:30Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 21 Aug 2007 11:14:21 -0600\n\"Josh England\" <jjengla@sandia.gov> wrote:\n\n> Git doesn't seem to allow me to add an empty directory to the index, or\n> even nested empty directories.  Is there any way to do this?  What is\n> the reasoning?  I've got a use case where having empty directories in my\n> git repository would be *very* valuable.  Any information and help is\n> greatly appreciated.\n\nHi Josh,\n\nGit doesn't track empty directories.  There is a brief note about it in\nthe FAQ:\n\n http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9\n\nSean\n"},{"id":"51211","messageId":"fafumf$fb4$1@sea.gmane.org","threadId":"9600","inReplyTo":"1187716461.5986.71.camel@beauty","subject":"Re: empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-22T00:06:39Z","receivedAt":"2007-08-22T00:06:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josh England wrote:\n\n\n> Git doesn't seem to allow me to add an empty directory to the index, or\n> even nested empty directories.  Is there any way to do this?  What is\n> the reasoning?  I've got a use case where having empty directories in my\n> git repository would be *very* valuable.  Any information and help is\n> greatly appreciated.\n\nGit does not track empty directories [yet], but you can use empty .gitignore\nfile trick to mark \"empty\" directories to be added.\n\nThere were some discussion about this on git mailing list (see archives),\nand this issue is most probably mentioned on GitFaq page in git wiki.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"51219","messageId":"fage86$hui$1@sea.gmane.org","threadId":"9600","inReplyTo":"1187716461.5986.71.camel@beauty","subject":"Re: empty directories","fromName":"Salikh Zakirov","fromEmail":"salikh@gmail.com","sentAt":"2007-08-22T04:31:39Z","receivedAt":"2007-08-22T04:31:39Z","isPatch":false,"sender":{"key":"salikh@gmail.com","avatar":"https://gravatar.com/avatar/952c102bb1dcf721dab8de4f5a11d276756a65d301d021f755e265cc3251efae?d=mp&s=160"},"body":"Josh England wrote:\n> Git doesn't seem to allow me to add an empty directory to the index, or\n> even nested empty directories.  Is there any way to do this?  What is\n> the reasoning?  I've got a use case where having empty directories in my\n> git repository would be *very* valuable.  Any information and help is\n> greatly appreciated.\n\nWhile the the other replies provided a historical background of how exactly\ngit handles directories and why it wasn't storing empty directories,\nthere is no fundamental reason for empty directories not being stored,\nit's just nobody got to implement it.\n\nLinus Torvalds posted an untested patch in a recent discussion and requested\nthat anyone interested in this functionality continued development and testing.\n\nDesign discussion: http://lists-archives.org/git/624494-empty-directories.html\nPatch: http://marc.info/?l=git&m=118480075313827&w=2\n\nJohannes Schindelin also posted an alternative implementation, which emulates\nempty dirs by adding empty .gitignore placeholder to the index.\nhttp://marc.info/?l=git&m=118484785410247&w=2\n\nYou could also read the long discussion of the subtle semantic issues that storing empty\ndirectories introduces in the mail thread accessible from above links.\n"},{"id":"51275","messageId":"alpine.LFD.0.999.0708221144160.30176@woody.linux-foundation.org","threadId":"9600","inReplyTo":"fage86$hui$1@sea.gmane.org","subject":"Re: empty directories","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-22T18:46:15Z","receivedAt":"2007-08-22T18:46:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Aug 2007, Salikh Zakirov wrote:\n> \n> Linus Torvalds posted an untested patch in a recent discussion and requested\n> that anyone interested in this functionality continued development and testing.\n\nThat untested patch was seriously broken - it didn't do the sorting of \nempty directories right. So it would need a lot of other work.\n\nSo I'm firmly back in the \"just add a '.gitignore' file to the directory\" \ncamp.\n\nOr you can fake it out entirely by making it an empty subproject, which \nalso gives you an empty directory.\n\n\t\t\tLinus\n"},{"id":"51280","messageId":"86fy2bcrj2.fsf@lola.quinscape.zz","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708221144160.30176@woody.linux-foundation.org","subject":"Re: empty directories","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-22T19:12:33Z","receivedAt":"2007-08-22T19:12:33Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Wed, 22 Aug 2007, Salikh Zakirov wrote:\n>> \n>> Linus Torvalds posted an untested patch in a recent discussion and\n>> requested that anyone interested in this functionality continued\n>> development and testing.\n>\n> That untested patch was seriously broken - it didn't do the sorting\n> of empty directories right.\n\nWell, it depends on where one wants to see directories sorted in the\nindex: the index sort order does not necessarily need to be the same\nas the repository sort order: merge conflict detection could benefit\nfrom sorting the directory \"early\" in the index.  Of course, this\nwould mean that one needed to stash away directories temporarily while\nprocessing the index until the corresponding tree in the repository\ncomes up.\n\n> So it would need a lot of other work.\n\nWith either choice of sort order, yes.  One place or the other.\n\n-- \nDavid Kastrup\n"},{"id":"51293","messageId":"1187817948.5986.159.camel@beauty","threadId":"9600","inReplyTo":"20070821134030.b763e9d3.seanlkml@sympatico.ca","subject":"Re: empty directories","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-22T21:25:48Z","receivedAt":"2007-08-22T21:25:48Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Wed, 22 Aug 2007, Linus Torvalds wrote:\n> On Wed, 22 Aug 2007, Salikh Zakirov wrote:\n> > \n> > Linus Torvalds posted an untested patch in a recent discussion and requested\n> > that anyone interested in this functionality continued development and testing.\n> \n> That untested patch was seriously broken - it didn't do the sorting of \n> empty directories right. So it would need a lot of other work.\n> \n> So I'm firmly back in the \"just add a '.gitignore' file to the directory\" \n> camp.\n\nWoah.  I just spent much of the morning reading the history of this\nthread. My eyes are still bleeding, but I think I'm sufficiently\ninformed enough to be dangerous.\n\nWithout actually sticking my head in the honey pot surrounded by giant\nbears, I just want to relate a revision control scenario that I've been\nwanting to solve for several years. I deploy/maintain many linux\nclusters that each have a single system image to boot all nodes on the\nmachines. My desire is to shove an *entire* image into a git\nrepository, and simply have it do the right thing.  Doing so and using\nclones/branches/merges to maintain these images would be extremely\nuseful.  I've attempted this concept with several SCMs using various\nworkarounds for each but have abandoned each attempt mainly due to\nperformance issues.  Git shows the best performance by far (to the\npoint of actually being usable) for this purpose.\n\nForget about special files as those are almost certainly a lost cause.\nI'm willing to use .gitignore in empty directories until a better\nsolution presents itself.  The main need is for file\nownership/permission, which has been touched on before.  When I clone\nan image, I really want an *identical* clone, in every way.  It seems\nas though git had this functionality but scrapped it due to issues with\numask and merge type problems?  So the question is:  would there be any\nway to bring this functionality back as a non-default configurable\noption?  For those of us who need the functionality, we'd be more than\nwilling to live with some of the side-effects.\n\nThe alternatives (involving wrappers and strict policy) just haven't\nbeen idiot-proof enough to be truly viable.  It almost has to be a\nbuilt-in capability.  It looks like Nax is doing something close to\nthis.  Is there anyone else using trying to use git in a similar way?\n\n-JE\n\nPS:  I know this falls outside of git's intended use, but its the\nclosest thing to something that could work.\n"},{"id":"51306","messageId":"alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org","threadId":"9600","inReplyTo":"1187817948.5986.159.camel@beauty","subject":"Re: empty directories","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-22T23:25:21Z","receivedAt":"2007-08-22T23:25:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Aug 2007, Josh England wrote:\n>\n> The main need is for file ownership/permission, which has been touched \n> on before.  When I clone an image, I really want an *identical* clone, \n> in every way.  It seems as though git had this functionality but \n> scrapped it due to issues with umask and merge type problems?\n\nWell, git had all permission bits, but never ownership. And yes, using \nmore than the one user-x-bit ended up being totally unusable for source \ncode, because of different people having different umask, so we \neffectively dropped the permission bits too (although the data format was \nretained, so we could re-introduce then with some flag that says \"honor \nall permission bits, not just the x bit\").\n\nBut the ownership thing we've never even tried to support, since it was so \nobviously not something that was appropriate for a distributed project. So \nif you want an identical clone with ownership and (full) permissions, you \nreally do need to have some alternate way to fill in the blanks.\n\nI've argued that \".gitattributes\" may be an acceptable alternate, \nespecially since ownership is often something that is less than \"per \nfile\", and more often \"has certain patterns\".\n\n> So the question is:  would there be any way to bring this functionality \n> back as a non-default configurable option?  For those of us who need the \n> functionality, we'd be more than willing to live with some of the \n> side-effects.\n\nFull permissions might be easy enough to resurrect, but since it's still \npointless without ownership, that really isn't even relevant.\n\nBut if .gitattributes would work, you probably could introduce both full \npermissions and ownership rules there. We read git attributes for *other* \nreasons when checking files out _anyway_, ie we need the CRLF attribute \nstuff, so adding ownership attributes would not be at all odd.\n\n\t\tLinus\n"},{"id":"51308","messageId":"faihgf$hg6$1@sea.gmane.org","threadId":"9600","inReplyTo":"1187817948.5986.159.camel@beauty","subject":"Re: empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-22T23:40:30Z","receivedAt":"2007-08-22T23:40:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: Josh England <jjengla@sandia.gov>, git@vger.kernel.org]\n\nJosh England wrote:\n\n> [...]  The main need is for file\n> ownership/permission, which has been touched on before.  When I clone\n> an image, I really want an *identical* clone, in every way.  It seems\n> as though git had this functionality but scrapped it due to issues with\n> umask and merge type problems?  So the question is:  would there be any\n> way to bring this functionality back as a non-default configurable\n> option?  For those of us who need the functionality, we'd be more than\n> willing to live with some of the side-effects.\n> \n> The alternatives (involving wrappers and strict policy) just haven't\n> been idiot-proof enough to be truly viable.  It almost has to be a\n> built-in capability.  It looks like Nax is doing something close to\n> this.  Is there anyone else using trying to use git in a similar way?\n\nCheck out (via e.g. http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\nwiki page) IsiSetup which is tool to manage configuration files (including\npermissions) which uses git as engine, and metastore which is meant as\ntool to use in appropriate hook for storing/restoring permissions etc.\n\nAnd as Linus told you, if you have time to work on it, you can try to\nmake .gitattributes work for this...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"51309","messageId":"85sl6bjf9q.fsf@lola.goethe.zz","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org","subject":"Re: empty directories","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-22T23:55:29Z","receivedAt":"2007-08-22T23:55:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> Full permissions might be easy enough to resurrect, but since it's\n> still pointless without ownership, that really isn't even relevant.\n\nI'd not call it entirely pointless without ownership: under most\nsystems, only root can do chown, so for example a private backup of a\nhome directory usually has unique ownership (and nothing but the\nnormal ownership could be restored by a user, anyway).\n\nHowever, once the user is member of more than a single group and\nactually makes _use_ of that, we are getting on thin ice.  But at\nleast different group ownership is usually much better contained (and\nthus reconstructible manually in the case of an emergency) as the\npermissions are.\n\nSince tracking permissions would be a per-project decision (nothing\nelse makes any sense), it should be workable to amend the tree records\nthemselves by adding ownership and ACL and whatever else optionally\nright there in-place if one figures out a good syntax for it.\n\nOne still needs to come up with a good and flexible way to implement\npolicies: what kind of permissions/ownership data will be let into the\nrepository from workdir/pushing, and what won't?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51376","messageId":"1187882648.5986.171.camel@beauty","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org","subject":"Re: empty directories","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-23T15:24:08Z","receivedAt":"2007-08-23T15:24:08Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Wed, 2007-08-22 at 16:25 -0700, Linus Torvalds wrote:\n> But if .gitattributes would work, you probably could introduce both full \n> permissions and ownership rules there. We read git attributes for *other* \n> reasons when checking files out _anyway_, ie we need the CRLF attribute \n> stuff, so adding ownership attributes would not be at all odd.\n\nOK, this looks like it has the desired effect.  commits/pulls/etc catch\nand update the execute bit.  I'll try to find how .gitattributes hooks\nin.  Any pointers/tips are appreciated.\n\n-JE\n"},{"id":"51407","messageId":"1187905879.5986.199.camel@beauty","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org","subject":"tracking perms/ownership [was: empty directories]","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-23T21:51:19Z","receivedAt":"2007-08-23T21:51:19Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Wed, 2007-08-22 at 16:25 -0700, Linus Torvalds wrote:\n> But if .gitattributes would work, you probably could introduce both full \n> permissions and ownership rules there. We read git attributes for *other* \n> reasons when checking files out _anyway_, ie we need the CRLF attribute \n> stuff, so adding ownership attributes would not be at all odd.\n\nSo here's the initial thought.  Create two new gitattributes, 'perms'\nand 'ownership', which will track perms/ownership for files matching the\ngiven pattern.\n\nLooking at the index struct, it already has fields in it for file mode\nuid and gid (woohoo!).  It looks like an addition to\nbuiltin-update-index.c could set those fields (if the gitattribute is\nset) the same way as how the execute bit is flipped with chmod_path().\nI haven't found where the chmod is done at checkout/clone time, but the\nquestion is:  If the mode, uid, and gid are stuffed in the index, will\ngit diff simply just work to recognize permission/ownership changes?  Is\nthis the right approach? What kind of merging issues will need to be\nworried about?\n\n-JE\n"},{"id":"51409","messageId":"7vtzqpsy3q.fsf@gitster.siamese.dyndns.org","threadId":"9600","inReplyTo":"1187905879.5986.199.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-23T22:08:25Z","receivedAt":"2007-08-23T22:08:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Josh England\" <jjengla@sandia.gov> writes:\n\n> Looking at the index struct, it already has fields in it for file mode\n> uid and gid (woohoo!).\n\nI can see that storing textual names in gitattributes and having\nthe root user run git so that it can chown(), would work.\n\nBut this is only about checkout.  After you chown a file in the\nwork tree and run update-index, next write-tree would not record\nit, as there is no place in tree objects to record uid/gid.\nYou would need to arrange so that a matching change is made in\nthe gitattributes file if you go that route.\n\nIf you had:\n\n\tetc/*\t\towner=root\n        etc/frotz\towner=nobody\n\nin gitattributes, and you did a checkout.  You chown etc/nitfol\nwith \"chown printer etc/nitfol\".  Somebody needs to add a line\n\n\tetc/nitfol\towner=printer\n\nto gitattributes before you make the commit.  Maybe the chown\nwas not about etc/nitfol but about making etc/frotz owned by\nroot.  Then you would, instead of adding the etc/nitfol line,\nremove existing etc/frotz line so that earlier glob would\ncapture and express the idea of making everything owned by\nroot.  I suspect this would get rather tricky quickly.\n\nOf course, you would need to worry about resolving merge\nconflicts of gitattributes file, too.\n"},{"id":"51410","messageId":"alpine.LFD.0.999.0708231626580.30176@woody.linux-foundation.org","threadId":"9600","inReplyTo":"7vtzqpsy3q.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-23T23:30:21Z","receivedAt":"2007-08-23T23:30:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Aug 2007, Junio C Hamano wrote:\n>\n> \"Josh England\" <jjengla@sandia.gov> writes: \n> > Looking at the index struct, it already has fields in it for file mode\n> > uid and gid (woohoo!).\n> \n> I can see that storing textual names in gitattributes and having\n> the root user run git so that it can chown(), would work.\n\nWell, the nice thing is that even non-root can actually resolve merge \nconflicts and generally use the archive, even if non-root obviously cannot \nthen actually set the files to those users/groups!\n\nSo handling ownership outside of the actual filesystem, in a separate file \nthat git tracks, actually allows you to do things that you couldn't \notherwise sanely do.\n\nIt obviously does have downsides:\n\n> But this is only about checkout.  After you chown a file in the\n> work tree and run update-index, next write-tree would not record\n> it, as there is no place in tree objects to record uid/gid.\n\nThis is a direct consequence of allowing non-root to actually work with \nsuch a repository: the git-tracked ownership information simply is \nseparate, and \"git update-index\" and friends will never do anything about \nit, since they just can't rely on the *filesystem* user/group information \nanyway (because normal users would never be allowed to set it, anyway).\n\n\t\tLinus\n"},{"id":"51419","messageId":"85ir75h2zb.fsf@lola.goethe.zz","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708231626580.30176@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-24T06:16:08Z","receivedAt":"2007-08-24T06:16:08Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Thu, 23 Aug 2007, Junio C Hamano wrote:\n>>\n>> \"Josh England\" <jjengla@sandia.gov> writes: \n>> > Looking at the index struct, it already has fields in it for file mode\n>> > uid and gid (woohoo!).\n>> \n>> I can see that storing textual names in gitattributes and having\n>> the root user run git so that it can chown(), would work.\n>\n> Well, the nice thing is that even non-root can actually resolve\n> merge conflicts and generally use the archive, even if non-root\n> obviously cannot then actually set the files to those users/groups!\n>\n> So handling ownership outside of the actual filesystem, in a\n> separate file that git tracks, actually allows you to do things that\n> you couldn't otherwise sanely do.\n\nWell, about that \"sane\" bit: I don't see an application for tracking\nunrestorable ownership values.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51424","messageId":"alpine.LFD.0.999.0708232327100.25853@woody.linux-foundation.org","threadId":"9600","inReplyTo":"85ir75h2zb.fsf@lola.goethe.zz","subject":"Re: tracking perms/ownership","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-24T06:37:17Z","receivedAt":"2007-08-24T06:37:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Aug 2007, David Kastrup wrote:\n> >\n> > So handling ownership outside of the actual filesystem, in a\n> > separate file that git tracks, actually allows you to do things that\n> > you couldn't otherwise sanely do.\n> \n> Well, about that \"sane\" bit: I don't see an application for tracking\n> unrestorable ownership values.\n\nUmm. Like an RPM spec file?\n\nThe thing you \"don't see an application\" for is exactly the kind of things \nthat people very much ALREADY DO. \n\nThere are tons of different setups for setting up user and group ownership \n(and things like permission) in almost any project. And I can pretty much \n*guarantee* you that none of them depend on actually having ownership on \nthe files themselves.\n\nIn git, just for fun, do\n\n\tgit grep defattr\n\nor even just look into the Makefile, and think about what lines like that\n\n\t$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'\n\nthing means, and why it has a \"755\" there, and why other Makefiles quite \noften have things like \"-o bin\" etc on such lines!\n\nSee? Those ownership things are restorable *as*root*, but that doesn't \nmean that everybody should do development as root. In fact, I'd argue that \nany system that is set up so that you have to develop and merge things \nwhile being root is pretty damn broken.\n\nWhich means that any such environment *has* to encode the owndership \n*separately* from the actual filesystem ownership. Because doing it in the \nfilesystem simply isn't sane.\n\nSo yes, you could have an insane piece of crap that actually tracks file \nownership in the filesystem, and requires people to be root.\n\nOr you could use a \".gitattributes\" file or similar _external_ tracking \nmethod that allows even people who cannot actually set ownership to work \nwith it.\n\nYour choice. But I know which one I'd choose.\n\n\t\t\tLinus\n"},{"id":"51427","messageId":"1187940171.6357.59.camel@beauty","threadId":"9600","inReplyTo":"7vtzqpsy3q.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T07:22:51Z","receivedAt":"2007-08-24T07:22:51Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote: \n> \"Josh England\" <jjengla@sandia.gov> writes:\n> \n> > Looking at the index struct, it already has fields in it for file mode\n> > uid and gid (woohoo!).\n> \n> I can see that storing textual names in gitattributes and having\n> the root user run git so that it can chown(), would work.\n> \n> But this is only about checkout.  After you chown a file in the\n> work tree and run update-index, next write-tree would not record\n> it, as there is no place in tree objects to record uid/gid.\n> You would need to arrange so that a matching change is made in\n> the gitattributes file if you go that route.\n\nThat's ok.  Any place to store the data is fine by me.  I'm just\nconcerned about some comments I saw in attrs.c <line13>:\n/*\nThe basic design decision here is that we are not going to have insanely\nlarge number of attributes.\nThis is a randomly chosen prime.\n*/\n#define HASHSIZE 257\n\nUsing a brute force perm/ownership attribute set for every file,\nassuming a modestly populated linux distribution image having upwards of\n150,000 files/directories in it, thats sticking over 100,000 attributes\ninto some .gitattributes file somewhere.  Do you think the gitattributes\nsystem can handle this kind of abuse?\n\n> If you had:\n> \n> \tetc/*\t\towner=root\n>         etc/frotz\towner=nobody\n> \n> in gitattributes, and you did a checkout.  You chown etc/nitfol\n> with \"chown printer etc/nitfol\".  Somebody needs to add a line\n> \n> \tetc/nitfol\towner=printer\n> \n> to gitattributes before you make the commit.\n\nUnless this 'somebody' is an automated process that will never fly. I\nwant git to do it for me when the right config/attr is set (maybe at\nupdate_index time).  Thats where my concern about the gitattributes\nsystem comes from.  What's going to happen when I stick 150,000 (est)\nattributes in there?\n\n> Maybe the chown\n> was not about etc/nitfol but about making etc/frotz owned by\n> root.  Then you would, instead of adding the etc/nitfol line,\n> remove existing etc/frotz line so that earlier glob would\n> capture and express the idea of making everything owned by\n> root.  I suspect this would get rather tricky quickly.\n\nMaybe doable though.  Starting from the root of the tree, traverse\ndownwards and only add new attributes when a file or dir's ownership\nhas changed from the parent, maybe.  This could optimize away many of\nthe attributes needed.  I think a good place might be right in\nindex_path() because the lstat data is fresh and accessible.  Writing\nattrs out to file if necessary should hopefully not add too much overhead.\n\n-JE\n"},{"id":"51429","messageId":"1187941133.6357.75.camel@beauty","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708232327100.25853@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T07:38:53Z","receivedAt":"2007-08-24T07:38:53Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Thu, 2007-08-23 at 23:37 -0700, Linus Torvalds wrote:\n> \n> On Fri, 24 Aug 2007, David Kastrup wrote:\n> > >\n> > > So handling ownership outside of the actual filesystem, in a\n> > > separate file that git tracks, actually allows you to do things that\n> > > you couldn't otherwise sanely do.\n> > \n> > Well, about that \"sane\" bit: I don't see an application for tracking\n> > unrestorable ownership values.\n> \n> Umm. Like an RPM spec file?\n> \n> The thing you \"don't see an application\" for is exactly the kind of things \n> that people very much ALREADY DO. \n> \n> There are tons of different setups for setting up user and group ownership \n> (and things like permission) in almost any project. And I can pretty much \n> *guarantee* you that none of them depend on actually having ownership on \n> the files themselves.\n> \n> In git, just for fun, do\n> \n> \tgit grep defattr\n> \n> or even just look into the Makefile, and think about what lines like that\n> \n> \t$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'\n> \n> thing means, and why it has a \"755\" there, and why other Makefiles quite \n> often have things like \"-o bin\" etc on such lines!\n\nYes. Permission bits are useful.  I wouldn't want a umask clobbering\nsome /bin directory to 0644 or some such.\n\n> See? Those ownership things are restorable *as*root*, but that doesn't \n> mean that everybody should do development as root. In fact, I'd argue\n>  that any system that is set up so that you have to develop and merge\n>  things while being root is pretty damn broken.\n\nIf your repository is a full system image (my extreme case), developing\nas root (installing packages, altering configs) is *required* if you\nexpect the image to boot/behave properly.  Squashing ownership in this\ncase would undoubtedly break many things.\n\n> Which means that any such environment *has* to encode the owndership \n> *separately* from the actual filesystem ownership. Because doing it in the \n> filesystem simply isn't sane.\n> \n> So yes, you could have an insane piece of crap that actually tracks file \n> ownership in the filesystem, and requires people to be root.\n\nThis is what I've done with SVN.  The mechanisms to save/restore\nperms/ownership can be run as hooks before checkin and after checkout.\nThe performance is pretty depressing even without running those hooks\nevery time.  I'm just hoping that using .gitattribues will perform\nreasonably well.\n\n> Or you could use a \".gitattributes\" file or similar _external_ tracking \n> method that allows even people who cannot actually set ownership to work \n> with it.\n\nYes, although it would be nice if a clone or a pull tells me (running as\na user) that the ownership being set doesn't match the uid/gid in the\nattribute file.  Element of least surprise.  For those actually\nrequesting the behavior, a little extra verbosity seems pretty\nacceptable.\n\n-JE\n"},{"id":"51430","messageId":"7vd4xds7oj.fsf@gitster.siamese.dyndns.org","threadId":"9600","inReplyTo":"1187940171.6357.59.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-24T07:39:08Z","receivedAt":"2007-08-24T07:39:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Josh England\" <jjengla@sandia.gov> writes:\n\n> That's ok.  Any place to store the data is fine by me.  I'm just\n> concerned about some comments I saw in attrs.c <line13>:\n> /*\n> The basic design decision here is that we are not going to have insanely\n> large number of attributes.\n> This is a randomly chosen prime.\n> */\n> #define HASHSIZE 257\n\nThat talks about the size of the vocabulary of attribute names,\nsuch as \"diff\", \"crlf\", \"merge\".  IIRC, you need two more\n(owner, perm) or maybe three (group), not 150k.\n"},{"id":"51433","messageId":"86mywhfk17.fsf@lola.quinscape.zz","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708232327100.25853@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-24T07:50:44Z","receivedAt":"2007-08-24T07:50:44Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\n[copied to gmane after sending personal copy by accident, since mails\n of me don't arrive on the list from my work account.  Sorry for the\n duplication.]\n\nLinus Torvalds <torvalds@linux-foundation.org> writes:\n\n\n[make install]\n\n> See? Those ownership things are restorable *as*root*, but that\n> doesn't mean that everybody should do development as root. In fact,\n> I'd argue that any system that is set up so that you have to develop\n> and merge things while being root is pretty damn broken.\n>\n> Which means that any such environment *has* to encode the owndership\n> *separately* from the actual filesystem ownership. Because doing it\n> in the filesystem simply isn't sane.\n\nBut in this case you have a work directory and an installation\ndirectory.  And you have an installation procedure.  No tracking is\ninvolved at all.\n\n> So yes, you could have an insane piece of crap that actually tracks\n> file ownership in the filesystem, and requires people to be root.\n\nIn your example, neither installed files nor ownership are tracked in\nthe filesystem.  Both are \"tracked\" in the Makefile.  Or rather than\nbeing tracked, they are explicitly catered for by the user.\n\n> Or you could use a \".gitattributes\" file or similar _external_\n> tracking method that allows even people who cannot actually set\n> ownership to work with it.\n\ngit is a content _tracker_.  It tracks contents, also contents that\nmove around.  If it can't track the permissions moving around as well,\nit's sort of pointless to integrate this into git: if you have to\nmanage the stuff yourself, anyway, there is no point in creating the\nillusion that it is done by git.\n\n> Your choice. But I know which one I'd choose.\n\nThat's fine.  But you don't actually need git at all to implement your\nchoice, so this is orthogonal to whether having an option to do it\ninside of git might be worth having.\n\n-- \nDavid Kastrup\n"},{"id":"51434","messageId":"1187943598.6357.99.camel@beauty","threadId":"9600","inReplyTo":"7vd4xds7oj.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T08:19:58Z","receivedAt":"2007-08-24T08:19:58Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 00:39 -0700, Junio C Hamano wrote:\n> \"Josh England\" <jjengla@sandia.gov> writes:\n> \n> > That's ok.  Any place to store the data is fine by me.  I'm just\n> > concerned about some comments I saw in attrs.c <line13>:\n> > /*\n> > The basic design decision here is that we are not going to have insanely\n> > large number of attributes.\n> > This is a randomly chosen prime.\n> > */\n> > #define HASHSIZE 257\n> \n> That talks about the size of the vocabulary of attribute names,\n> such as \"diff\", \"crlf\", \"merge\".  IIRC, you need two more\n> (owner, perm) or maybe three (group), not 150k.\n\nOK that's comforting.  The 150k above though is not # of attribute\n*types* (perms/uid/gid or whatever), it is number of attribute *entries*\nin a .gitattributes file (eg:  /etc/sudoers  mode=0440 uid=0 gid=0).\nHopefully it shouldn't actually be as high as 150k, i don't know.\n\n-JE\n"},{"id":"51436","messageId":"Pine.LNX.4.64.0708241136301.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9600","inReplyTo":"1187905879.5986.199.camel@beauty","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-24T09:38:13Z","receivedAt":"2007-08-24T09:38:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 23 Aug 2007, Josh England wrote:\n\n> On Wed, 2007-08-22 at 16:25 -0700, Linus Torvalds wrote:\n> > But if .gitattributes would work, you probably could introduce both full \n> > permissions and ownership rules there. We read git attributes for *other* \n> > reasons when checking files out _anyway_, ie we need the CRLF attribute \n> > stuff, so adding ownership attributes would not be at all odd.\n> \n> So here's the initial thought.  Create two new gitattributes, 'perms'\n> and 'ownership', which will track perms/ownership for files matching the\n> given pattern.\n\nI wonder why you do not just use the \"smudge\" and \"clean\" attributes, and \nstore the ownership _and_ the permissions in .gitacls.\n\nYes, _maybe_ it is something other people might want, too, but let's start \nquick & easy, no?\n\nCiao,\nDscho\n"},{"id":"51438","messageId":"20070824095217.GB16853@coredump.intra.peff.net","threadId":"9600","inReplyTo":"Pine.LNX.4.64.0708241136301.16728@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-24T09:52:17Z","receivedAt":"2007-08-24T09:52:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 24, 2007 at 11:38:13AM +0200, Johannes Schindelin wrote:\n\n> > So here's the initial thought.  Create two new gitattributes, 'perms'\n> > and 'ownership', which will track perms/ownership for files matching the\n> > given pattern.\n> \n> I wonder why you do not just use the \"smudge\" and \"clean\" attributes, and \n> store the ownership _and_ the permissions in .gitacls.\n> \n> Yes, _maybe_ it is something other people might want, too, but let's start \n> quick & easy, no?\n\nYes, I think that is a much better idea. Perhaps they aren't that\npopular among this crowd, but it seems silly to develop in this\ndirection and not at least consider people storing actual ACLs (or even\nother extended attributes). An already-standard format like that\nproduced by 'getfacl' should make this pretty trivial (and handles\nregular unix permissions at the same time).\n\n-Peff\n"},{"id":"51440","messageId":"20070824100524.GA17348@coredump.intra.peff.net","threadId":"9600","inReplyTo":"Pine.LNX.4.64.0708241136301.16728@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-24T10:05:24Z","receivedAt":"2007-08-24T10:05:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 24, 2007 at 11:38:13AM +0200, Johannes Schindelin wrote:\n\n> I wonder why you do not just use the \"smudge\" and \"clean\" attributes, and \n> store the ownership _and_ the permissions in .gitacls.\n\nThinking about this more, are you proposing:\n\n1. Clean and smudge every file, looking up the attributes in .gitacls.\nIn that case, I think they are not sufficient because the filter script\nreceives only the blob content on stdin, but never sees the filename.\n\nor\n\n2. Clean and smudge .gitacls, munging the file permissions as a side\neffect. In this case, won't some git operations that write the files\nbreak your permissions (i.e., if I update \"foo\" but not .gitacls, then\nthe .gitacls filter won't be run and I will be left with git's default\npermissions).\n\n-Peff\n"},{"id":"51450","messageId":"1187970632.6357.108.camel@beauty","threadId":"9600","inReplyTo":"20070824095217.GB16853@coredump.intra.peff.net","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T15:50:32Z","receivedAt":"2007-08-24T15:50:32Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 05:52 -0400, Jeff King wrote:\n> On Fri, Aug 24, 2007 at 11:38:13AM +0200, Johannes Schindelin wrote:\n> \n> > > So here's the initial thought.  Create two new gitattributes, 'perms'\n> > > and 'ownership', which will track perms/ownership for files matching the\n> > > given pattern.\n> > \n> > I wonder why you do not just use the \"smudge\" and \"clean\" attributes, and \n> > store the ownership _and_ the permissions in .gitacls.\n> > \n> > Yes, _maybe_ it is something other people might want, too, but let's start \n> > quick & easy, no?\n> \n> Yes, I think that is a much better idea. Perhaps they aren't that\n> popular among this crowd, but it seems silly to develop in this\n> direction and not at least consider people storing actual ACLs (or even\n> other extended attributes). An already-standard format like that\n> produced by 'getfacl' should make this pretty trivial (and handles\n> regular unix permissions at the same time).\n\nDo you mean using acls through contrib/hooks/update-paranoid?  That is\nthe only place I see any mention of them.  clean and smudge seem out\nbecause they are passed blob objects and have no notion of pathname.  I\ndon't see how to use this for automatic storing/restoring of\nperms/ownership.\n\n-JE\n"},{"id":"51451","messageId":"1187971879.6357.117.camel@beauty","threadId":"9600","inReplyTo":"7vtzqpsy3q.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T16:11:19Z","receivedAt":"2007-08-24T16:11:19Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote:\n> Of course, you would need to worry about resolving merge\n> conflicts of gitattributes file, too.\n\nI'm still confused on things.  So, with all perms/ownership stored\nas .gitattributes, would mucking around with the index still be\nnecessary?  I'm not too sure what to do about merge conflicts.\n\n-JE\n"},{"id":"51452","messageId":"1187972825.6357.125.camel@beauty","threadId":"9600","inReplyTo":"1187971879.6357.117.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T16:27:05Z","receivedAt":"2007-08-24T16:27:05Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 10:11 -0600, Josh England wrote:\n> On Thu, 2007-08-23 at 15:08 -0700, Junio C Hamano wrote:\n> > Of course, you would need to worry about resolving merge\n> > conflicts of gitattributes file, too.\n> \n> I'm still confused on things.  So, with all perms/ownership stored\n> as .gitattributes, would mucking around with the index still be\n> necessary?  I'm not too sure what to do about merge conflicts.\n\nOK, let me know if this is completely off-base.  perms/ownership can be\nstored in the index at update-index time and restored maybe at\ncheckout-index time.  Calls to write-tree and read-tree can\nstore/retrieve the perms/ownership data from a .gitattributes file\nsomewhere; and something sane needs to be done about merging.  Does this\nsound reasonable enough for a first cut?\n\n-JE\n"},{"id":"51463","messageId":"E7DE807861E8474E8AC3DC7AC2C75EE50329676F@34093-EVS2C1.exchange.rackspace.com","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org","subject":"RE: empty directories","fromName":"Jason Garber","fromEmail":"jgarber@ionzoft.com","sentAt":"2007-08-24T17:10:10Z","receivedAt":"2007-08-24T17:10:10Z","isPatch":false,"sender":{"key":"jgarber@ionzoft.com","avatar":"https://gravatar.com/avatar/e8e5cac5f615739d425dd7232dc76313337cd76ad7b9f078694f74725409eae8?d=mp&s=160"},"body":"> But if .gitattributes would work, you probably could introduce both\nfull \n> permissions and ownership rules there. We read git attributes for\n*other* \n> reasons when checking files out _anyway_, ie we need the CRLF\nattribute \n> stuff, so adding ownership attributes would not be at all odd.\n>\n> \t\tLinus\n\nAnd as a side-note, it would be quite trivial to write a script to\ninitially populate a .gitattributes file cleanly (and regen when\nneeded).\n\n~ JasonG\n"},{"id":"51455","messageId":"alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org","threadId":"9600","inReplyTo":"86mywhfk17.fsf@lola.quinscape.zz","subject":"Re: tracking perms/ownership","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-24T17:51:35Z","receivedAt":"2007-08-24T17:51:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Aug 2007, David Kastrup wrote:\n> >\n> > Which means that any such environment *has* to encode the owndership\n> > *separately* from the actual filesystem ownership. Because doing it\n> > in the filesystem simply isn't sane.\n> \n> But in this case you have a work directory and an installation\n> directory.  And you have an installation procedure.  No tracking is\n> involved at all.\n\nI agree that the cases are different.\n\nI also agree that a tool that is *specialized* to only do basically \nbackups (or, equivalently, \"distributed installation\") would potentially \nbe a different issue, and there \"it will only run as root\" is a reasonable \nthing to do.\n\nBut git is, if anything, specialized the other way - which means that I \nthink it's perfectly fine to let it know about ownership, but it's *not* a \nvalid thing to do to then say \"only root can do it\". \n\nAlso, even with a distributed installer/backup thing, the fact is, \n\"ownership\" and \"permissions\" is simply not well-defined at a filesystem \nlevel. Are we talking just unix owner/group/mode here? That won't do for a \nlot of filesystems that have ACL's or other extended user/permission \ninformation. \n\n> In your example, neither installed files nor ownership are tracked in\n> the filesystem.  Both are \"tracked\" in the Makefile.  Or rather than\n> being tracked, they are explicitly catered for by the user.\n\nAnd I seriously am saying that that is the only way to handle things \nsanely in a distributed content tracker like git.\n\nBecause full permissions and ownership (think ACL's) simply aren't \n\"content\" enough. The way to _reliably_ turn them into \"content\" that can \nbe tracked, is to make it some form of file content.\n\nBecause otherwise, you will always hit situations where you simply cannot \naccess it sanely. Even as an administrator you might need to do some \nemergency fixup, but you may be on vacation, and the only thing you have \naccess to is some machine that you're not root on - and you'd like to send \na \"git bundle\" with the fix to your less-than-stellar stand-in that is \nknee-deep in sh*t because he doesn't know the system, and you're on some \nsunny tropical island.\n\nOr just imagine the case where you have slightly different setups for \ndifferent people - some have ACL's, some have just basic permissions. But \nyou want to maintain an image that works for both cases. What do you do?\n\nSee? If you just accept the fact that ownership and permissions are \ntotally \"separate content\" that is tracked AS CONTENT, and not as the \nfilesystem thing, you solve all these problems.\n\n> git is a content _tracker_.  It tracks contents, also contents that\n> move around.  If it can't track the permissions moving around as well,\n> it's sort of pointless to integrate this into git: if you have to\n> manage the stuff yourself, anyway, there is no point in creating the\n> illusion that it is done by git.\n\nFair enough - I'll certainly agree with the notion that we don't \nnecessarily need any integration of permissions/ownership into git at \nall, and you can always do it as a totally independent layer.\n\n> > Your choice. But I know which one I'd choose.\n> \n> That's fine.  But you don't actually need git at all to implement your\n> choice, so this is orthogonal to whether having an option to do it\n> inside of git might be worth having.\n\nBut I care about git having a *sane*design*, whether I use all the \nfeatures or not. Because I simply care about my tools at a higher level \nthan most users do. Which means that it doesn't matter whether I'll use \npermissions/ownership tracking or not - I still require that git do it \n*sanely* from my standpoint of having a good content tracker.\n\nAnd that means tracking those things *separately*, and not trying to mess \nup the \"tree\" structure, for example.\n\n\t\t\tLinus\n"},{"id":"51457","messageId":"1187979317.6357.155.camel@beauty","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T18:15:17Z","receivedAt":"2007-08-24T18:15:17Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 10:51 -0700, Linus Torvalds wrote:\n> Because full permissions and ownership (think ACL's) simply aren't \n> \"content\" enough. The way to _reliably_ turn them into \"content\" that can \n> be tracked, is to make it some form of file content.\n> \n> Because otherwise, you will always hit situations where you simply cannot \n> access it sanely. Even as an administrator you might need to do some \n> emergency fixup, but you may be on vacation, and the only thing you have \n> access to is some machine that you're not root on - and you'd like to send \n> a \"git bundle\" with the fix to your less-than-stellar stand-in that is \n> knee-deep in sh*t because he doesn't know the system, and you're on some \n> sunny tropical island.\n\nUsing the .gitattributes approach essentially does turn perms/ownership\ninto trackable content.  A non-root user could specify the ownership of\ncertain files just by editing the .gitattributes, much in the same way a\nnon-root user can create an initramfs filesystem.\n\n> Or just imagine the case where you have slightly different setups for \n> different people - some have ACL's, some have just basic permissions. But \n> you want to maintain an image that works for both cases. What do you do?\n\npunt  :)   Simple unix ownership and perms are a good first cut.  ACL's\ncould probably be handled in much the same way, but converting between\nunix perms and ACLs might have to be a separate attribute/filter\nentirely.\n\n> See? If you just accept the fact that ownership and permissions are \n> totally \"separate content\" that is tracked AS CONTENT, and not as the \n> filesystem thing, you solve all these problems.\n> \n> > git is a content _tracker_.  It tracks contents, also contents that\n> > move around.  If it can't track the permissions moving around as well,\n> > it's sort of pointless to integrate this into git: if you have to\n> > manage the stuff yourself, anyway, there is no point in creating the\n> > illusion that it is done by git.\n> \n> Fair enough - I'll certainly agree with the notion that we don't \n> necessarily need any integration of permissions/ownership into git at \n> all, and you can always do it as a totally independent layer.\n> \n> > > Your choice. But I know which one I'd choose.\n> > \n> > That's fine.  But you don't actually need git at all to implement your\n> > choice, so this is orthogonal to whether having an option to do it\n> > inside of git might be worth having.\n> \n> But I care about git having a *sane*design*, whether I use all the \n> features or not. Because I simply care about my tools at a higher level \n> than most users do. Which means that it doesn't matter whether I'll use \n> permissions/ownership tracking or not - I still require that git do it \n> *sanely* from my standpoint of having a good content tracker.\n> \n> And that means tracking those things *separately*, and not trying to mess \n> up the \"tree\" structure, for example.\n\nDo you think its OK to cache this stuff in the index, though?\nwrite-tree could then just dump the perms/ownership out as gitattributes\nsomewhere.\n\n-JE\n"},{"id":"51458","messageId":"alpine.LFD.0.999.0708241119140.25853@woody.linux-foundation.org","threadId":"9600","inReplyTo":"1187979317.6357.155.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-24T18:23:37Z","receivedAt":"2007-08-24T18:23:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Aug 2007, Josh England wrote:\n> \n> Do you think its OK to cache this stuff in the index, though?\n> write-tree could then just dump the perms/ownership out as gitattributes\n> somewhere.\n\nI'd really prefer not.\n\nThe index state - very much by design - matches the filesystem \"stat\" \ndata, not the internal git data. So \"ce_size\" matches the checked-out \nsize, not the native git data size (ie with CRLF conversion, it matches \nnot the checked-in data, but the filesystem version). \n\nAnd the same really goes for ce_uid/ce_gid: they have to match what's on \nthe filesystem, because they are used not to track user information, but \nto verify that the inode data is valid!\n\nYeah, we could just ignore them for checking \"is the inode the same\", but \nthat would actually end up *defeating* the point of what you want to do: \nat that point, we'd also obviously ignore it when ownership changes!\n\n\t\t\tLinus\n"},{"id":"51462","messageId":"1187981803.6357.173.camel@beauty","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708241119140.25853@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T18:56:43Z","receivedAt":"2007-08-24T18:56:43Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 11:23 -0700, Linus Torvalds wrote:\n> \n> On Fri, 24 Aug 2007, Josh England wrote:\n> > \n> > Do you think its OK to cache this stuff in the index, though?\n> > write-tree could then just dump the perms/ownership out as gitattributes\n> > somewhere.\n> \n> I'd really prefer not.\n> \n> The index state - very much by design - matches the filesystem \"stat\" \n> data, not the internal git data. So \"ce_size\" matches the checked-out \n> size, not the native git data size (ie with CRLF conversion, it matches \n> not the checked-in data, but the filesystem version). \n\nThat's exactly what I'm after, too: having a snapshot of all lstat data\nin the index, because I don't want to have to do an extra stat\nsomewhere.\n\n> And the same really goes for ce_uid/ce_gid: they have to match what's on \n> the filesystem, because they are used not to track user information, but \n> to verify that the inode data is valid!\n\nBut the stat data (even uid/gid) is in there nonetheless, right?  If\neverything is in there already I wouldn't need to add a thing.  I just\nwant to access the index cache rather than hitting the filesystem\ndirectly.\n\n> Yeah, we could just ignore them for checking \"is the inode the same\", but \n> that would actually end up *defeating* the point of what you want to do: \n> at that point, we'd also obviously ignore it when ownership changes!\n\nIf we view the index as being a snapshot of the filesystem, and if\nperm/ownership data is stored as .gitattributes in the actual repo, \nthen the perm/ownership engine just has to reconcile between the index\nand the .gitattributes file for both the read and write case.\nDifferences in the write case would result in the .gitattributes being\nupdated.  Differences in the read case would result in chown/chmod being\nrun in the working tree.  Does this make sense?\n\n-JE\n"},{"id":"51465","messageId":"200708242133.27324.robin.rosenberg.lists@dewire.com","threadId":"9600","inReplyTo":"1187979317.6357.155.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-08-24T19:33:26Z","receivedAt":"2007-08-24T19:33:26Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 24 augusti 2007 skrev Josh England:\n> punt  :)   Simple unix ownership and perms are a good first cut.  ACL's\n> could probably be handled in much the same way, but converting between\n> unix perms and ACLs might have to be a separate attribute/filter\n> entirely.\n\nYou cannot convert between traditional unix permissisons and ACL:s. Either you\nmanage ACL:s or not. The traditional form is fortunately just a special case of posix\nACL:s. Here is a getfacl example. Just feed it to setfacl to set permissions according\nto the dump.\n\n$ getfacl README\n# file: README\n# owner: me\n# group: me\nuser::rw-\ngroup::r--\ngroup:apache:rwx\nmask::rwx\nother::r--\n\nWindows ACL.s are different though. \n\n-- robin\n"},{"id":"51471","messageId":"7vfy28d5yl.fsf@gitster.siamese.dyndns.org","threadId":"9600","inReplyTo":"1187981803.6357.173.camel@beauty","subject":"Re: tracking perms/ownership","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-24T20:37:38Z","receivedAt":"2007-08-24T20:37:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Josh England\" <jjengla@sandia.gov> writes:\n\n> But the stat data (even uid/gid) is in there nonetheless, right?  If\n> everything is in there already I wouldn't need to add a thing.  I just\n> want to access the index cache rather than hitting the filesystem\n> directly.\n\nBut to use that data you would need extra code to move things\nfrom there to gitattributes, wouldn't you?  I can see that you\ncould \"stage\" change of ownership in the index and attempt to\ncommit by nonexisting\n\n\tgit update-index --chown root foo.c\n\nwhich would say \"foo.c is now owned by uid #0\", but before the\nnext git-commit-tree runs, somebody (namely, \"git-commit\") has\nto run a possibly enhanced \"git diff-files\" (traditionally\nuid/gid are NOT part of contents at all, so diff-files would not\nsay ownership has changed between the filesystem and index in\nwhat way at all) to notice that ownership has changed, and\nupdate .gitattributes.\n\nThen you need to also \"git update-index\" the .gitattributes as\nwell, to record the ownership change in the commit.  What if the\nuser had unrelated changes that the user does not want to commit\nin .gitattributes?\n\nIt will quickly become a mess.\n\nIt would rather be more effective for the user action \"I want to\nchange the ownership of foo.c to root\" to cause a direct\nmanipulation of .gitattributes file.  For this, we can add a\nnice wrapper if there is a need, but the initial cut could be\njust running \"${EDITOR-${VISUAL-vi}} .gitattributes\", nothing\nmore.\n\nThe user can say \"git diff\" to view .gitattributes changes, and\nif that is what he wants (maybe he wants to do \"git add -i\" to\npick only the hunk about the ownership change for the next\ncommit), the change to .gitattributes can be committed.\n"},{"id":"51472","messageId":"20070824205820.GA19152@coredump.intra.peff.net","threadId":"9600","inReplyTo":"1187970632.6357.108.camel@beauty","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-08-24T20:58:20Z","receivedAt":"2007-08-24T20:58:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 24, 2007 at 09:50:32AM -0600, Josh England wrote:\n\n> > direction and not at least consider people storing actual ACLs (or even\n> > other extended attributes). An already-standard format like that\n> \n> Do you mean using acls through contrib/hooks/update-paranoid?  That is\n> the only place I see any mention of them.  clean and smudge seem out\n> because they are passed blob objects and have no notion of pathname.  I\n> don't see how to use this for automatic storing/restoring of\n> perms/ownership.\n\nNo, I mean filesystem ACLs. Your complaint is that git stores only the\nfile _content_, not some specific metadata that you want (owner, group,\npermissions). My point is that there is _other_ metadata, too (such as\nPOSIX ACLs) that could be stored. Even if you don't want to store them,\nif you are extending git's capabilities, it makes sense to at least\nconsider how to handle those cases, too.\n\nBut yes, clean and smudge don't get the pathname. It would be a fairly\ntrivial patch, though, so maybe I'll play with it.\n\n-Peff\n"},{"id":"51474","messageId":"1187990811.6357.232.camel@beauty","threadId":"9600","inReplyTo":"7vfy28d5yl.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-08-24T21:26:51Z","receivedAt":"2007-08-24T21:26:51Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Fri, 2007-08-24 at 13:37 -0700, Junio C Hamano wrote:\n> It would rather be more effective for the user action \"I want to\n> change the ownership of foo.c to root\" to cause a direct\n> manipulation of .gitattributes file.  For this, we can add a\n> nice wrapper if there is a need, but the initial cut could be\n> just running \"${EDITOR-${VISUAL-vi}} .gitattributes\", nothing\n> more.\n> \n> The user can say \"git diff\" to view .gitattributes changes, and\n> if that is what he wants (maybe he wants to do \"git add -i\" to\n> pick only the hunk about the ownership change for the next\n> commit), the change to .gitattributes can be committed.\n\nThat sounds fine, and is certainly easier to implement.  The only catch\nis that whatever wrapper is updating .gitattributes will have to walk\nthe working tree doing lstat() calls, which seems redundant (and costly)\nto me.\n\n-JE\n"},{"id":"51475","messageId":"85wsvkfwnc.fsf@lola.goethe.zz","threadId":"9600","inReplyTo":"alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org","subject":"Re: tracking perms/ownership","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-24T21:30:31Z","receivedAt":"2007-08-24T21:30:31Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Fri, 24 Aug 2007, David Kastrup wrote:\n>\n>> In your example, neither installed files nor ownership are tracked\n>> in the filesystem.  Both are \"tracked\" in the Makefile.  Or rather\n>> than being tracked, they are explicitly catered for by the user.\n>\n> And I seriously am saying that that is the only way to handle things\n> sanely in a distributed content tracker like git.\n\nWell, maybe _if_ you are using it as a distributed content tracker.\nBut git is excellent at tracking contents (and resolving conflicts and\nmerged) even if you _don't_ distribute.\n\nAnyway, my beef with using something like .gitattributes or similar\nfor tracking permissions is twofold:\n\na) if I am tracking a directory, having to track additional files\nclutters the directory.  So if one uses a separate file for tracking,\nit should be able to use a file that is not actually in the work tree.\nBut it still needs to be versioned.  One could possibly fudge this by\ncreating an artificial work tree with the tracked directory being in a\nsubdirectory of it, but that's all pretty dorky.\n\nb) merge resolution and movement tracking.  Delegating stuff to a file\nand using the _file_ merging and tracking mechanisms is just not\nreally the same thing.  So it would be nice to at least have\n\"pluggable merge strategies\" for particular files, or treat\ngitattributes special with regard to merging, anyway.\n\nPersonally, I'm leaning towards a pluggable policy system containing\nrules how permission information is represented textually in the\nrepository (that would allow acls and uid gid information), how the\nindex is updated from repo and workdir and vice versa.  The default\npolicy would just talk about 777 or 666 (or 775 and 644) as it does\nnow.\n\nWe already have a policy flag that optionally blocks the information\nflow from/to the index regarding executable bits.  So it is not like\nthe concept is alien.\n\nOn the matter of taste: I feel fine about storing numerical uid/gid\ndata in the index, but I am already getting queasy with the idea of\nstoring them numerically in the repository: that's a place where I\nfind symbolic names more appropriate.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51506","messageId":"Pine.LNX.4.64.0708251629320.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9600","inReplyTo":"20070824100524.GA17348@coredump.intra.peff.net","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-25T14:30:41Z","receivedAt":"2007-08-25T14:30:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Aug 2007, Jeff King wrote:\n\n> On Fri, Aug 24, 2007 at 11:38:13AM +0200, Johannes Schindelin wrote:\n> \n> > I wonder why you do not just use the \"smudge\" and \"clean\" attributes, and \n> > store the ownership _and_ the permissions in .gitacls.\n> \n> Thinking about this more, are you proposing:\n> \n> 1. Clean and smudge every file, looking up the attributes in .gitacls.\n\nYes, this is what I thought about.  And I'd just have looked up the file \nname by sha1.\n\nThe clean/smudge filter would update .gitacls in the index, too...\n\nCiao,\nDscho\n"},{"id":"51507","messageId":"Pine.LNX.4.64.0708251630460.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9600","inReplyTo":"20070824205820.GA19152@coredump.intra.peff.net","subject":"Re: tracking perms/ownership [was: empty directories]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-25T14:31:36Z","receivedAt":"2007-08-25T14:31:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Aug 2007, Jeff King wrote:\n\n> On Fri, Aug 24, 2007 at 09:50:32AM -0600, Josh England wrote:\n> \n> > > direction and not at least consider people storing actual ACLs (or even\n> > > other extended attributes). An already-standard format like that\n> > \n> > Do you mean using acls through contrib/hooks/update-paranoid?  That is\n> > the only place I see any mention of them.  clean and smudge seem out\n> > because they are passed blob objects and have no notion of pathname.  I\n> > don't see how to use this for automatic storing/restoring of\n> > perms/ownership.\n> \n> No, I mean filesystem ACLs. Your complaint is that git stores only the\n> file _content_, not some specific metadata that you want (owner, group,\n> permissions). My point is that there is _other_ metadata, too (such as\n> POSIX ACLs) that could be stored. Even if you don't want to store them,\n> if you are extending git's capabilities, it makes sense to at least\n> consider how to handle those cases, too.\n> \n> But yes, clean and smudge don't get the pathname. It would be a fairly\n> trivial patch, though, so maybe I'll play with it.\n\nYes, please do.  Even if you do not end up implementing the perms/owner \ntracking using the clean/smudge filter, it seems odd that the filter \nshould not get the filename.\n\nCiao,\nDscho\n"},{"id":"51510","messageId":"7vy7fz659s.fsf@gitster.siamese.dyndns.org","threadId":"9600","inReplyTo":"Pine.LNX.4.64.0708251630460.16728@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: tracking perms/ownership","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-25T14:46:39Z","receivedAt":"2007-08-25T14:46:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Yes, please do.  Even if you do not end up implementing the perms/owner \n> tracking using the clean/smudge filter, it seems odd that the filter \n> should not get the filename.\n\nPlease don't.  Go back to the list discussion and recall why any\nfilters that depends on nothing but contents are bad (\"crlf good,\nkeyword bad\").  Don't feed paths to filters.\n"},{"id":"51519","messageId":"7v4pin5rwz.fsf@gitster.siamese.dyndns.org","threadId":"9600","inReplyTo":"7vy7fz659s.fsf@gitster.siamese.dyndns.org","subject":"Re: tracking perms/ownership","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-25T19:35:08Z","receivedAt":"2007-08-25T19:35:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>> Yes, please do.  Even if you do not end up implementing the perms/owner \n>> tracking using the clean/smudge filter, it seems odd that the filter \n>> should not get the filename.\n>\n> Please don't.  Go back to the list discussion and recall why any\n> filters that depends on nothing but contents are bad (\"crlf good,\n> keyword bad\").  Don't feed paths to filters.\n\nGaaaaah.  I meant \"a filter whose action depends on anything\nother than contents\".  Those other things include history (so\n\"commit ID\" is out) and pathnames.\n"}]}