{"thread":{"id":"9838","subject":"Re: Track /etc directory using Git","startedAt":"2007-09-14T17:31:06Z","lastAt":"2007-10-03T00:52:25Z","messageCount":72,"participants":["Thomas Harning Jr.","Nicolas Vilz","martin f krafft","Johannes Schindelin","David Kastrup","Pierre Habouzit","Grzegorz Kulewski","Daniel Barkalow","Randal L. Schwartz","david@lang.hm","Junio C Hamano","Jan Hudec","Francis Moreau","Josh England","David Härdeman","Julian Phillips"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53038","messageId":"e47324780709141031t79981b04q3a91984668ea723e@mail.gmail.com","threadId":"9838","inReplyTo":"20070914091545.GA26432@piper.oerlikon.madduck.net","subject":"Re: Track /etc directory using Git","fromName":"Thomas Harning Jr.","fromEmail":"harningt@gmail.com","sentAt":"2007-09-14T17:31:06Z","receivedAt":"2007-09-14T17:31:06Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"On 9/14/07, martin f krafft wrote:\n> also sprach Francis Moreau [2007.09.14.1008 +0200]:\n> > Did you find an alternative to git in this case ?\n>\n> No, and I did not look anywhere, but I know of no other VCS that can\n> adequatly track permissions.\nHas anyone checked out metastore? http://repo.or.cz/w/metastore.git\n... there's an XML error in there somewhere, so its not loading the\n'main' page, but http://repo.or.cz/w/metastore.git?a=shortlog should\nwork.\n\nIt looks like it could work.... any thoughts on this?\n\n\n-- \nThomas Harning Jr.\n"},{"id":"53056","messageId":"20070914212643.GA10970@amy.inscure.wireless.home.vilz.de","threadId":"9838","inReplyTo":"e47324780709141031t79981b04q3a91984668ea723e@mail.gmail.com","subject":"Re: Track /etc directory using Git","fromName":"Nicolas Vilz","fromEmail":"niv@iaglans.de","sentAt":"2007-09-14T21:26:43Z","receivedAt":"2007-09-14T21:26:43Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"On Fri, Sep 14, 2007 at 01:31:06PM -0400, Thomas Harning Jr. wrote:\n> On 9/14/07, martin f krafft wrote:\n> > also sprach Francis Moreau [2007.09.14.1008 +0200]:\n> > > Did you find an alternative to git in this case ?\n> >\n> > No, and I did not look anywhere, but I know of no other VCS that can\n> > adequatly track permissions.\n> Has anyone checked out metastore? http://repo.or.cz/w/metastore.git\n> ... there's an XML error in there somewhere, so its not loading the\n> 'main' page, but http://repo.or.cz/w/metastore.git?a=shortlog should\n> work.\n> \n> It looks like it could work.... any thoughts on this?\n\nI use that tool. If you just have one branch, it works. With the\ncommit-hook, which also updates the metadata, you have current\npermission tracking. \n\nThere is a lack of a checkout-hook, which sets the permissions, so you\nhave to remeber todo a metastore -a after you checked out a revision.\n\nBut if you have several branches which fork the master branch and try to\nrebase the branches on master, you get trouble, because the metadata gets\ncorrupted somehow. I will think about a solution on this sometime.\n\nNicolas\n"},{"id":"53112","messageId":"20070915132632.GA31610@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"20070914212643.GA10970@amy.inscure.wireless.home.vilz.de","subject":"metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-15T13:26:32Z","receivedAt":"2007-09-15T13:26:32Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Thomas Harning Jr. [2007.09.14.1931 +0200]:\n> > No, and I did not look anywhere, but I know of no other VCS that can\n> > adequatly track permissions.\n> Has anyone checked out metastore? http://repo.or.cz/w/metastore.git\n> ... there's an XML error in there somewhere, so its not loading the\n> 'main' page, but http://repo.or.cz/w/metastore.git?a=shortlog should\n> work.\n\nThis looks interesting, though I guess getfacl/setfacl and\ngetfattr/setfattr can pretty much do the same job, especially if you\ncan call them from shell scripts/hooks (except for mtime). Or did\nI misunderstand something?\n\nThe problem with metdata getting corrupted, which Nicolas reported,\nmay well have to do with the use of a single file. It may be worth\nto consider using a shadow hierarchy of files, each containing the\nmetadata, e.g. for a project with foo, and bar/foo and bar/baz\nfiles, you might have\n\n .metastore/foo\n .metastore/bar/..dir\n .metastore/bar/foo\n .metastore/bar/baz\n\nand each file could just be an rfc822-style file:\n\n Owner: root\n Group: root\n Mode: 4754\n Mtime: 1234567890\n Fattr-: \n Fattr-: \n\nThis would be my approach, which should probably be a little better\nat preventing corruption.\n\nAnyway, this *really* should go into git itself!\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"i like wagner's music better than anybody's. it is so loud that one\n can talk the whole time without other people hearing what one says.\"\n -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53115","messageId":"Pine.LNX.4.64.0709151507310.28586@racer.site","threadId":"9838","inReplyTo":"20070915132632.GA31610@piper.oerlikon.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-15T14:10:01Z","receivedAt":"2007-09-15T14:10:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 15 Sep 2007, martin f krafft wrote:\n\n> The problem with metdata getting corrupted, which Nicolas reported,\n> may well have to do with the use of a single file.\n\nThen the tool is corrupt. Introducing a shadow hierarchy, as you propose, \nis very inefficient.\n\n> Anyway, this *really* should go into git itself!\n\nNo. Git is a source code management system. Everything else that you can \ndo with it is a bonus, a second class citizen. Should we really try to \nsupport your use case, we will invariably affect the primary use case.\n\nCiao,\nDscho\n"},{"id":"53119","messageId":"85ejh0aua9.fsf@lola.goethe.zz","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151507310.28586@racer.site","subject":"Re: metastore","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-15T14:16:14Z","receivedAt":"2007-09-15T14:16:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sat, 15 Sep 2007, martin f krafft wrote:\n>\n>> The problem with metdata getting corrupted, which Nicolas reported,\n>> may well have to do with the use of a single file.\n>\n> Then the tool is corrupt. Introducing a shadow hierarchy, as you\n> propose, is very inefficient.\n>\n>> Anyway, this *really* should go into git itself!\n>\n> No. Git is a source code management system. Everything else that\n> you can do with it is a bonus, a second class citizen. Should we\n> really try to support your use case, we will invariably affect the\n> primary use case.\n\nThat's what bad design is all about, after all.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53121","messageId":"20070915142932.GB27494@artemis.corp","threadId":"9838","inReplyTo":"20070914212643.GA10970@amy.inscure.wireless.home.vilz.de","subject":"Re: Track /etc directory using Git","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-15T14:29:32Z","receivedAt":"2007-09-15T14:29:32Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Sep 14, 2007 at 09:26:43PM +0000, Nicolas Vilz wrote:\n> On Fri, Sep 14, 2007 at 01:31:06PM -0400, Thomas Harning Jr. wrote:\n> > On 9/14/07, martin f krafft wrote:\n> > > also sprach Francis Moreau [2007.09.14.1008 +0200]:\n> > > > Did you find an alternative to git in this case ?\n> > >\n> > > No, and I did not look anywhere, but I know of no other VCS that can\n> > > adequatly track permissions.\n> > Has anyone checked out metastore? http://repo.or.cz/w/metastore.git\n> > ... there's an XML error in there somewhere, so its not loading the\n> > 'main' page, but http://repo.or.cz/w/metastore.git?a=shortlog should\n> > work.\n> > \n> > It looks like it could work.... any thoughts on this?\n> \n> I use that tool. If you just have one branch, it works. With the\n> commit-hook, which also updates the metadata, you have current\n> permission tracking. \n> \n> There is a lack of a checkout-hook, which sets the permissions, so you\n> have to remeber todo a metastore -a after you checked out a revision.\n\n Note that having metastore run by a hook makes it unsuitable for /etc\nversioning, because you may have short period of times during which\ns3kr3t files are readable by more people that what it should be.\n\n The sole sane way to do that would be to track permissions, acls,\nwhatever _in_ git. Though, I'm still not convinced that it is such a\ngood idea at all. I mean for source code you absolutely _don't_ want git\nto track permissions (outside from the +x bit). You don't want git to\ntry to chown your files to \"madcoder:madcoder\" because I was the last\none committing. So that would mean that you want sometimes to track\npermissions, sometimes not. So you need a bunch of tools to list files\nwhose permissions have to be tracked, and whose permissions don't need\nto be.\n\n I fear that you'll end up with quite a big bloat of git, for a use\ncase that is fairly limited.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"53123","messageId":"20070915145437.GA12875@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151507310.28586@racer.site","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-15T14:54:37Z","receivedAt":"2007-09-15T14:54:37Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Johannes Schindelin [2007.09.15.1610 +0200]:\n> No. Git is a source code management system. Everything else that\n> you can do with it is a bonus, a second class citizen. Should we\n> really try to support your use case, we will invariably affect the\n> primary use case.\n\nI thought git was primarily a content tracker... so it all comes\ndown to how to define content, doesn't it? But either way, we need\nnot discuss that because that definition depends a lot on context\nand purpose and thus cannot be answered once and for all.\n\nI understand that for the primary use case, tracking nothing more\nthan +x makes sense and should not be interfered with. This is why\nI was proposing a policy-based approach. The primary use case is\nunaffected, it's the default policy. Someone may choose to track\nother mode bits or file/inode attributes, according to one of\nseveral policies available with git, or even a custom policy. In\nthat case, the repository needs to be appropriately configured.\n\nThe reason why I say this should be done inside git rather than with\nhooks and an external tool, such as metastore is quite simple: git\nknows about every content entity in any tree of a repo and already\nhas a data node for each object. Rather than introducing a parallel\nobject database (shadow hierarchy or single file), it would make\na lot more sense and be way more robust to attach additional\ninformation to these object nodes, wouldn't it?\n\nSo with \"appropriately configured\" above, I meant that one should be\nable to say\n\n git-config core.track all\n\nor\n\n git-config core.track mode+attr\n\nor the default:\n\n git-config core.track 7666\n (read that as a umask, which masks out everything but the three\n x bits. I made it 7666 instead of 7677 because core.umask and\n core.sharedrepository then override the group and world bits if\n needed)\n\nand have git do the right thing, rather than expecting those who\nwant to track more than the executable bit to assemble a brittle set\nof hooks and metadata collectors+applicators and hope it all works.\n\nI understand also that this is not top priority for git, which is\nwhy I said earlier in the thread that the real difficulty might be\nto get Junio to accept a patch. But I think that the patch would be\nrather contained and small, having it all configurable would make it\nunintrusive, and if we all test it real well, it should pass as\na bonus. After all, git can e.g upload patches to IMAP boxes, which\nin my world clearly is bonus material as well.\n\nCheers,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"the well-bred contradict other people.\n the wise contradict themselves.\"\n -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53126","messageId":"20070915152455.GA16223@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"20070915142932.GB27494@artemis.corp","subject":"Re: Track /etc directory using Git","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2007-09-15T15:24:55Z","receivedAt":"2007-09-15T15:24:55Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Pierre Habouzit [2007.09.15.1629 +0200]:\n> I fear that you'll end up with quite a big bloat of git, for a use\n> case that is fairly limited.\n\nI think it doesn't get bloated until you try to support the model of\ntracking different stuff for different files in the same repo. If\nyou just track one set of data across all files in the repo, I don't\nthink it'll cause too much bloat.\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \ngentoo: the performance placebo.\n"},{"id":"53127","messageId":"20070915152724.GC27494@artemis.corp","threadId":"9838","inReplyTo":"20070915152455.GA16223@piper.oerlikon.madduck.net","subject":"Re: Track /etc directory using Git","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-15T15:27:24Z","receivedAt":"2007-09-15T15:27:24Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sat, Sep 15, 2007 at 03:24:55PM +0000, martin f krafft wrote:\n> also sprach Pierre Habouzit [2007.09.15.1629 +0200]:\n> > I fear that you'll end up with quite a big bloat of git, for a use\n> > case that is fairly limited.\n> \n> I think it doesn't get bloated until you try to support the model of\n> tracking different stuff for different files in the same repo. If\n> you just track one set of data across all files in the repo, I don't\n> think it'll cause too much bloat.\n\n Yeah but if the stuff is opaque to git, you'll definitely end up with\nsecurity issues, which makes it also a no-go for /etc versionning.\n\n Note that I don't specifically care about git being able to deal with\n/etc, I was just pointing out some issues I can see with it, but I'm\nneiter in favor nor against it.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"53128","messageId":"20070915154225.GA17704@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"20070915152724.GC27494@artemis.corp","subject":"Re: Track /etc directory using Git","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2007-09-15T15:42:25Z","receivedAt":"2007-09-15T15:42:25Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Pierre Habouzit [2007.09.15.1727 +0200]:\n> > I think it doesn't get bloated until you try to support the model of\n> > tracking different stuff for different files in the same repo. If\n> > you just track one set of data across all files in the repo, I don't\n> > think it'll cause too much bloat.\n> \n> Yeah but if the stuff is opaque to git, you'll definitely end up with\n> security issues, which makes it also a no-go for /etc versionning.\n\nWith \"opaque to git\" do you mean \"implemented outside git\"?\n\nI'd say if done properly inside git, the security issues could be\nprevented.\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \n\"this sentence contradicts itself -- no actually it doesn't.\"\n -- douglas hofstadter\n"},{"id":"53132","messageId":"Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net","threadId":"9838","inReplyTo":"20070915145437.GA12875@piper.oerlikon.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Grzegorz Kulewski","fromEmail":"kangur@polcom.net","sentAt":"2007-09-15T16:22:59Z","receivedAt":"2007-09-15T16:22:59Z","isPatch":false,"sender":{"key":"kangur@polcom.net","avatar":null},"body":"On Sat, 15 Sep 2007, martin f krafft wrote:\n> also sprach Johannes Schindelin [2007.09.15.1610 +0200]:\n>> No. Git is a source code management system. Everything else that\n>> you can do with it is a bonus, a second class citizen. Should we\n>> really try to support your use case, we will invariably affect the\n>> primary use case.\n>\n> I thought git was primarily a content tracker... so it all comes\n> down to how to define content, doesn't it? But either way, we need\n> not discuss that because that definition depends a lot on context\n> and purpose and thus cannot be answered once and for all.\n>\n> I understand that for the primary use case, tracking nothing more\n> than +x makes sense and should not be interfered with. This is why\n> I was proposing a policy-based approach. The primary use case is\n> unaffected, it's the default policy. Someone may choose to track\n> other mode bits or file/inode attributes, according to one of\n> several policies available with git, or even a custom policy. In\n> that case, the repository needs to be appropriately configured.\n>\n> The reason why I say this should be done inside git rather than with\n> hooks and an external tool, such as metastore is quite simple: git\n> knows about every content entity in any tree of a repo and already\n> has a data node for each object. Rather than introducing a parallel\n> object database (shadow hierarchy or single file), it would make\n> a lot more sense and be way more robust to attach additional\n> information to these object nodes, wouldn't it?\n>\n> So with \"appropriately configured\" above, I meant that one should be\n> able to say\n>\n> git-config core.track all\n>\n> or\n>\n> git-config core.track mode+attr\n>\n> or the default:\n>\n> git-config core.track 7666\n> (read that as a umask, which masks out everything but the three\n> x bits. I made it 7666 instead of 7677 because core.umask and\n> core.sharedrepository then override the group and world bits if\n> needed)\n>\n> and have git do the right thing, rather than expecting those who\n> want to track more than the executable bit to assemble a brittle set\n> of hooks and metadata collectors+applicators and hope it all works.\n>\n> I understand also that this is not top priority for git, which is\n> why I said earlier in the thread that the real difficulty might be\n> to get Junio to accept a patch. But I think that the patch would be\n> rather contained and small, having it all configurable would make it\n> unintrusive, and if we all test it real well, it should pass as\n> a bonus. After all, git can e.g upload patches to IMAP boxes, which\n> in my world clearly is bonus material as well.\n\nI also think such configuration option would be cool.\n\nNot only for tracking /etc or /home but also for example for \"web \napplications\" (for example in PHP). In that case file and directory \npermissions can be as important as the source code tracked and it is pain \nto chmod (and sometimes chown) all files to different values after each \ncheckout. Not speaking about potential race.\n\n\nThanks,\n\nGrzegorz Kulewski\n"},{"id":"53130","messageId":"20070915163209.GA18508@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"38b2ab8a0709140120k50f5b474oc8a841ea0a5fda50@mail.gmail.com","subject":"Re: Track /etc directory using Git","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-15T16:32:09Z","receivedAt":"2007-09-15T16:32:09Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Francis Moreau [2007.09.14.1020 +0200]:\n> The funny thing is that this tool is based on git/cogito but the\n> scm used to manage it is darc.\n\nThey switched to git after running their heads too many times\nagainst darcs walls.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nif god had meant for us to be naked,\nwe would have been born that way.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53133","messageId":"85642bc1ep.fsf@lola.goethe.zz","threadId":"9838","inReplyTo":"20070915163209.GA18508@piper.oerlikon.madduck.net","subject":"Re: Track /etc directory using Git","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-15T16:57:02Z","receivedAt":"2007-09-15T16:57:02Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"martin f krafft writes:\n\n> also sprach Francis Moreau [2007.09.14.1020 +0200]:\n>> The funny thing is that this tool is based on git/cogito but the\n>> scm used to manage it is darc.\n>\n> They switched to git after running their heads too many times\n> against darcs walls.\n\nSince they are not using git as a source code management system nor\ndarcs as a versioned file system, it is not particularly funny.\n\nIt's like being proud when the neighbor watchmaker borrows a hammer:\n\"ah, I always told him that a hammer is the ultimate device for\nrepairing a clock\".\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53140","messageId":"Pine.LNX.4.64.0709151842350.28586@racer.site","threadId":"9838","inReplyTo":"Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-15T17:43:54Z","receivedAt":"2007-09-15T17:43:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 15 Sep 2007, Grzegorz Kulewski wrote:\n\n> On Sat, 15 Sep 2007, martin f krafft wrote:\n> > I understand also that this is not top priority for git, which is why \n> > I said earlier in the thread that the real difficulty might be to get \n> > Junio to accept a patch. But I think that the patch would be rather \n> > contained and small, having it all configurable would make it \n> > unintrusive, and if we all test it real well, it should pass as a \n> > bonus. After all, git can e.g upload patches to IMAP boxes, which in \n> > my world clearly is bonus material as well.\n> \n> I also think such configuration option would be cool.\n\nWhy don't you just give it a try? Hack on git, make it work for what you \nwant to do, clean it up, make a nice patch series, post it here.\n\nThen we'll talk.\n\nCiao,\nDscho\n"},{"id":"53142","messageId":"Pine.LNX.4.64.0709151430040.5298@iabervon.org","threadId":"9838","inReplyTo":"20070915145437.GA12875@piper.oerlikon.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-09-15T19:56:42Z","receivedAt":"2007-09-15T19:56:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 15 Sep 2007, martin f krafft wrote:\n\n> also sprach Johannes Schindelin [2007.09.15.1610 +0200]:\n> > No. Git is a source code management system. Everything else that\n> > you can do with it is a bonus, a second class citizen. Should we\n> > really try to support your use case, we will invariably affect the\n> > primary use case.\n> \n> I thought git was primarily a content tracker... so it all comes\n> down to how to define content, doesn't it? But either way, we need\n> not discuss that because that definition depends a lot on context\n> and purpose and thus cannot be answered once and for all.\n> \n> I understand that for the primary use case, tracking nothing more\n> than +x makes sense and should not be interfered with. This is why\n> I was proposing a policy-based approach. The primary use case is\n> unaffected, it's the default policy. Someone may choose to track\n> other mode bits or file/inode attributes, according to one of\n> several policies available with git, or even a custom policy. In\n> that case, the repository needs to be appropriately configured.\n\nConfiguration options only apply to the local aspects of the repository. \nThat is, when you clone a repository, you don't get the configuration \noptions from it, in general. And changing configuration options on a \nrepository does not have any effect on the content it contains. So \nconfiguration options aren't appropriate.\n\n> The reason why I say this should be done inside git rather than with\n> hooks and an external tool, such as metastore is quite simple: git\n> knows about every content entity in any tree of a repo and already\n> has a data node for each object. Rather than introducing a parallel\n> object database (shadow hierarchy or single file), it would make\n> a lot more sense and be way more robust to attach additional\n> information to these object nodes, wouldn't it?\n\nGit doesn't have any way to represent owners or groups, and they would \nneed to be represented carefully in order to make sense across multiple \ncomputers. If you're adding support for metadata-as-content (for more than \n\"is this a script?\"), you should be able to cover all of the common cases \nof extended stuff, like AFS-style ACLs. And if you want to allow \nmeaningful development with this mechanism (as opposed to just archival of \na sequence of states of a live system), the normal case will be that the \nmetadata beyond +x is manipulated by ordinary users in some way other than \nmodifying their working directory. So the normal case here will be like \nworking on a filesystem that doesn't support symlinks or an executable bit \nwhen this is important content.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"53144","messageId":"Pine.LNX.4.64.0709152310380.28586@racer.site","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151430040.5298@iabervon.org","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-15T22:14:22Z","receivedAt":"2007-09-15T22:14:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 15 Sep 2007, Daniel Barkalow wrote:\n\n> Git doesn't have any way to represent owners or groups, and they would \n> need to be represented carefully in order to make sense across multiple \n> computers.\n\n[speaking mostly to the proponents of git-as-a-backup-tool]\n\nWhile at it, you should invent a fallback what to do when the owner is not \npresent on the system you check out on. And a fallback when checking out \non a filesystem that does not support owners.\n\nAnd a fallback when a non-root user uses it.\n\nOh, and while you're at it (you said that it would be nice not to restrict \ngit in any way: \"it is a content tracker\") support the Windows style \n\"Group-or-User-or-something:[FRW]\" ACLs.\n\nLooking forward to your patches,\nDscho\n"},{"id":"53150","messageId":"86veaby050.fsf@blue.stonehenge.com","threadId":"9838","inReplyTo":"Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net","subject":"Re: metastore","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-09-15T23:33:31Z","receivedAt":"2007-09-15T23:33:31Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Grzegorz\" == Grzegorz Kulewski writes:\n\nGrzegorz> Not only for tracking /etc or /home but also for example for \"web\nGrzegorz> applications\" (for example in PHP). In that case file and directory\nGrzegorz> permissions can be as important as the source code tracked and it is pain to\nGrzegorz> chmod (and sometimes chown) all files to different values after each\nGrzegorz> checkout. Not speaking about potential race.\n\nUh, works just fine for me to manage my web site content. The point is\nthat I treat git for what it is... a source code management system.\nAnd then I have a Makefile that \"installs\" my source code into the live\ndirectory, with the right modes during installation.\n\nWhy does everyone keep wanting \"work dir == live dir\". Ugh! The work dir is\nthe *source*... it gets *copied* into your live dir *somehow*. And *that* is\nwhere the meta information needs to be. In that \"somehow\".\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"53155","messageId":"Pine.LNX.4.64.0709151733260.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"86veaby050.fsf@blue.stonehenge.com","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T00:37:14Z","receivedAt":"2007-09-16T00:37:14Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 15 Sep 2007, Randal L. Schwartz wrote:\n\n>>>>>> \"Grzegorz\" == Grzegorz Kulewski writes:\n>\n> Grzegorz> Not only for tracking /etc or /home but also for example for \"web\n> Grzegorz> applications\" (for example in PHP). In that case file and directory\n> Grzegorz> permissions can be as important as the source code tracked and it is pain to\n> Grzegorz> chmod (and sometimes chown) all files to different values after each\n> Grzegorz> checkout. Not speaking about potential race.\n>\n> Uh, works just fine for me to manage my web site content. The point is\n> that I treat git for what it is... a source code management system.\n> And then I have a Makefile that \"installs\" my source code into the live\n> directory, with the right modes during installation.\n>\n> Why does everyone keep wanting \"work dir == live dir\". Ugh! The work dir is\n> the *source*... it gets *copied* into your live dir *somehow*. And *that* is\n> where the meta information needs to be. In that \"somehow\".\n\nthe problem is that at checkin you need to do the reverse process. the \nother tools that you use on the system work on the live dir, not the 'work \ndir', so it's only a 'work dir' in that git requires it as an staging step \nbetween the repository and the place where it's going to be used.\n\nDavid Lang\n"},{"id":"53158","messageId":"86r6kzxvnm.fsf@blue.stonehenge.com","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151733260.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-09-16T01:10:21Z","receivedAt":"2007-09-16T01:10:21Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"david\" == david writes:\n\n>> Why does everyone keep wanting \"work dir == live dir\". Ugh! The work dir is\n>> the *source*... it gets *copied* into your live dir *somehow*. And *that* is\n>> where the meta information needs to be. In that \"somehow\".\n\ndavid> the problem is that at checkin you need to do the reverse process. the\ndavid> other tools that you use on the system work on the live dir, not the\ndavid> 'work dir', so it's only a 'work dir' in that git requires it as an\ndavid> staging step between the repository and the place where it's going to\ndavid> be used.\n\nEh? Are we still talking about a \"website\", or \"/etc\"? I'm talking about the\nwebsite case. I don't do *anything* to the live site. When I want to add a\nfile, I add it to my dev repo, possibly modifying my Makefile, and then spit\nit out on my staging server. (You *do* have one of those, right?) Once I\nknow it's good, I push it to the live repo, and then \"go live\" with it. I\n*never* work on the files that are the result of \"make install\".\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"53159","messageId":"Pine.LNX.4.64.0709151737400.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709152310380.28586@racer.site","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T01:30:53Z","receivedAt":"2007-09-16T01:30:53Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 15 Sep 2007, Johannes Schindelin wrote:\n\n> On Sat, 15 Sep 2007, Daniel Barkalow wrote:\n>\n>> Git doesn't have any way to represent owners or groups, and they would\n>> need to be represented carefully in order to make sense across multiple\n>> computers.\n>\n> [speaking mostly to the proponents of git-as-a-backup-tool]\n>\n> While at it, you should invent a fallback what to do when the owner is not\n> present on the system you check out on. And a fallback when checking out\n> on a filesystem that does not support owners.\n>\n> And a fallback when a non-root user uses it.\n>\n> Oh, and while you're at it (you said that it would be nice not to restrict\n> git in any way: \"it is a content tracker\") support the Windows style\n> \"Group-or-User-or-something:[FRW]\" ACLs.\n\ngit has pre-commit hooks that could be used to gather the permission \ninformation and store it into a file.\n\ngit now has the ability to define cusom merge strategies for specific file \ntypes, which could be used to handle merges for the permission files.\n\nwhat git lacks the ability to do is to deal with special cases on \ncheckout.\n\nthe handling of gitattributes came really close, but there are two \nproblems remaining.\n\n1. whatever is trying to write the files with the correct permissions\n needs to be able to query the permission store before files are\n written. This needs to either be an API call into git to retreive the\n information for any file when it's written, or the ability to define a\n specific file to be checked out first so that it can be used for\n everything else.\n\n2. the ability to specify a custom routine/program to write the file out\n (assuming that it's being written to a filesystem not a pipe). this\n routine would be responsible for querying the permission store and\n doing 'the right thing' when the file is written during a checkout\n\nthere are some significant advantages of having the permission store be \njust a text file.\n\n1. it doesn't require a special API to a new datastore in git\n\n2. when working in an environment that doesn't allow for implementing the\n permissions (either a filesystem that can't store the permissions or\n when not working as root so that you can't set the ownership) the file\n can just be written and then edited with normal tools.\n\n3. normal merge tools do a reasonable job of merging them.\n\nhowever to do this git would need to gain the ability to say 'this \nfilename is special, it must be checked out before any other file is \nchecked out' (either on a per-directory or per-repository level)\n\nif this is acceptable then altering the routines that write the files to \nhave the additional option of calling a different routine based on the \nsettings in .gitattributes seems relativly simple. there should already be \nlogic to decect if it's writing to a pipe or a filesystem (it needs to \nknow if it should set the write bit if nothing else), and there's the \nexisting passthrough or custom routine logic for the crlf translation from \n.gitattributes. combining the logic of the two should handle the output \nissues.\n\nthe ability to handle /etc comes up every few months. it's got to be the \nmost common unimplemented request git has seen. Adding the nessasary hooks \nfor it to be done could end up being less effort then repeatedly telling \npeople that they shouldn't use git for that task (or should wrap git in \ntheir own scripts and use the result instead of useing git directly)\n\n\nso would changes like this be acceptable?\n\nDavid Lang\n"},{"id":"53160","messageId":"Pine.LNX.4.64.0709151831401.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151430040.5298@iabervon.org","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T01:35:13Z","receivedAt":"2007-09-16T01:35:13Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 15 Sep 2007, Daniel Barkalow wrote:\n\n>> The reason why I say this should be done inside git rather than with \n>> hooks and an external tool, such as metastore is quite simple: git \n>> knows about every content entity in any tree of a repo and already has \n>> a data node for each object. Rather than introducing a parallel object \n>> database (shadow hierarchy or single file), it would make a lot more \n>> sense and be way more robust to attach additional information to these \n>> object nodes, wouldn't it?\n>\n> Git doesn't have any way to represent owners or groups, and they would \n> need to be represented carefully in order to make sense across multiple \n> computers. If you're adding support for metadata-as-content (for more \n> than \"is this a script?\"), you should be able to cover all of the common \n> cases of extended stuff, like AFS-style ACLs. And if you want to allow \n> meaningful development with this mechanism (as opposed to just archival \n> of a sequence of states of a live system)\n\ndon't underestimate the usefullness of the ability to archive and restore \nsnapshots of a live system. just that ability would be wonderful to have.\n\nthe ability to checkout a copy of things elsewhere and tinker with it \nwould be better, but the lack of that doesn't eliminate the utility by any \nmeans.\n\nDavid Lang\n\n> , the normal case will be that \n> the metadata beyond +x is manipulated by ordinary users in some way \n> other than modifying their working directory. So the normal case here \n> will be like working on a filesystem that doesn't support symlinks or an \n> executable bit when this is important content.\n"},{"id":"53161","messageId":"Pine.LNX.4.64.0709151836240.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"86r6kzxvnm.fsf@blue.stonehenge.com","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T01:49:29Z","receivedAt":"2007-09-16T01:49:29Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 15 Sep 2007, Randal L. Schwartz wrote:\n\n>>>>>> \"david\" == david writes:\n>\n>>> Why does everyone keep wanting \"work dir == live dir\". Ugh! The work dir is\n>>> the *source*... it gets *copied* into your live dir *somehow*. And *that* is\n>>> where the meta information needs to be. In that \"somehow\".\n>\n> david> the problem is that at checkin you need to do the reverse process. the\n> david> other tools that you use on the system work on the live dir, not the\n> david> 'work dir', so it's only a 'work dir' in that git requires it as an\n> david> staging step between the repository and the place where it's going to\n> david> be used.\n>\n> Eh? Are we still talking about a \"website\", or \"/etc\"? I'm talking about the\n> website case. I don't do *anything* to the live site. When I want to add a\n> file, I add it to my dev repo, possibly modifying my Makefile, and then spit\n> it out on my staging server. (You *do* have one of those, right?) Once I\n> know it's good, I push it to the live repo, and then \"go live\" with it. I\n> *never* work on the files that are the result of \"make install\".\n\neven when working on a website it can be relavent.\n\nyes, when you are developing html you want to do it on a test server , \nmove it to staging, and then move to production. but it's also not \nuncommon to have web based tools that allow other people to make some \nchanges as well (for example, a bank's website is mostly maintained by \ntheir web development company, but the bank administraters want the \nability to change rate information instantly). sometimes this is \nimplemented by writing the info to a database and then querying that \ndatabase for every hit, but a far more efficiant way is to store that data \nin a file on the webserver, which can include modifying pages directly.\n\nbut yes, I was mostly thinking of /etc instead of the webserver when I \nwrote that.\n\nDavid Lang\n"},{"id":"53164","messageId":"Pine.LNX.4.64.0709160348110.28586@racer.site","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151737400.24221@asgard.lang.hm","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-16T02:48:54Z","receivedAt":"2007-09-16T02:48:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 15 Sep 2007, david@lang.hm wrote:\n\n> so would changes like this be acceptable?\n\nWould they be acceptable for you? If so, go ahead. If not, don't.\n\nHth,\nDscho\n"},{"id":"53165","messageId":"Pine.LNX.4.64.0709151958090.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709160348110.28586@racer.site","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T03:00:12Z","receivedAt":"2007-09-16T03:00:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Johannes Schindelin wrote:\n\n> On Sat, 15 Sep 2007, david@lang.hm wrote:\n>\n>> so would changes like this be acceptable?\n>\n> Would they be acceptable for you? If so, go ahead. If not, don't.\n\nfrankly, unless I am willing for fork git (which I am not) it matters a \nwhole lot less if such a change is acceptable to me then if it is \nacceptable to the maintainers.\n\nif it's not acceptable to the maintainers as a concept then it's not worth \ngoing to the effort of producing the patches as they will just be \nrejected.\n\nDavid Lang\n"},{"id":"53167","messageId":"20070916060859.GB24124@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151430040.5298@iabervon.org","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-16T06:08:59Z","receivedAt":"2007-09-16T06:08:59Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Daniel Barkalow [2007.09.15.2156 +0200]:\n> Configuration options only apply to the local aspects of the repository. \n> That is, when you clone a repository, you don't get the configuration \n> options from it, in general. And changing configuration options on a \n> repository does not have any effect on the content it contains. So \n> configuration options aren't appropriate.\n\nSure they are. Just like git-commit figures out your email address \nif user.email is missing from git-config, or core.sharedRepository \nor core.umask deal with permissions only when you tell them to, \nyou'd have to enable core.track or else git would just do what it\ndoes right now.\n\n> Git doesn't have any way to represent owners or groups, and they\n> would need to be represented carefully in order to make sense\n> across multiple computers. If you're adding support for\n> metadata-as-content (for more than \"is this a script?\"), you\n> should be able to cover all of the common cases of extended stuff,\n> like AFS-style ACLs.\n\nIdeally, git should be able to store an open-ended number of\nproperties for each object, yes.\n\n> And if you want to allow meaningful development with this\n> mechanism (as opposed to just archival of a sequence of states of\n> a live system), the normal case will be that the metadata beyond\n> +x is manipulated by ordinary users in some way other than\n> modifying their working directory.\n\nI have no idea what you mean with that.\n\n> So the normal case here will be like working on a filesystem that\n> doesn't support symlinks or an executable bit when this is\n> important content.\n\n... and yet, we support symlinks and executable files. But anyway,\nI really don't understand what you're trying to say.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"ist gott eine erfindung des teufels?\"\n - friedrich nietzsche\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53168","messageId":"20070916061411.GC24124@piper.oerlikon.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709152310380.28586@racer.site","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-16T06:14:11Z","receivedAt":"2007-09-16T06:14:11Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Johannes Schindelin [2007.09.16.0014 +0200]:\n> While at it, you should invent a fallback what to do when the\n> owner is not present on the system you check out on. And\n> a fallback when checking out on a filesystem that does not support\n> owners.\n\nLike rsync, git would use numerical UIDs (which are always present)\nby default, but could be told to try to map account names.\n\nIf the filesystem does not support owners, chown() would not exist.\nI actually tend to think of things the other way around: instead of\na fallback when chown() does not work (what would such a fallback be\nother than not chown()ing?), it would only try chown() if such\nfunctionality existed.\n\n> And a fallback when a non-root user uses it.\n\nThat's easy, Unix already provides you with that \"fallback\": pack up\n/etc in a tar and unpack it as a normal user...\n\n> Oh, and while you're at it (you said that it would be nice not to\n> restrict git in any way: \"it is a content tracker\") support the\n> Windows style \"Group-or-User-or-something:[FRW]\" ACLs.\n\nProvided we find a way to implement this in an extensible manner,\nthis should not be hard to do. I can't do it since I don't have\naccess to a Windows machine.\n\nYour statement does catch me off-guard though. Does git now\nofficially target Windows?\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nif you find a spelling mistake in the above, you get to keep it.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53173","messageId":"7vwsur590q.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151737400.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-16T08:06:45Z","receivedAt":"2007-09-16T08:06:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> git has pre-commit hooks that could be used to gather the permission\n> information and store it into a file.\n>\n> git now has the ability to define cusom merge strategies for specific\n> file types, which could be used to handle merges for the permission\n> files.\n> ...\n> There are some significant advantages of having the permission store\n> be just a text file.\n>\n> 1. it doesn't require a special API to a new datastore in git\n>\n> 2. when working in an environment that doesn't allow for implementing the\n> permissions (either a filesystem that can't store the permissions or\n> when not working as root so that you can't set the ownership) the file\n> can just be written and then edited with normal tools.\n>\n> 3. normal merge tools do a reasonable job of merging them.\n>\n> however to do this git would need to gain the ability to say 'this\n> filename is special, it must be checked out before any other file is\n> checked out' (either on a per-directory or per-repository level)\n\nI'd rather not implement it at such a low level where a true\n\"checkout\" happens. For one thing, I am afraid that the special\ncasing will affect the normal codepath too much and would make\nit into a maintenance nightmare. But more importantly, if you\nare switching between commits (this includes switching branches,\nchecking out a different commit to a detached HEAD, or\npulling/merging updates your HEAD and updates your work tree),\nand the contents of a path does not change between the original\ncommit and the switched-to commit, you may still have to\n\"checkout\" the external information for that path if your\n\"permission information file\" are different between these two\ncommits. To the underlying checkout aka \"two tree merge\"\noperation, that kind of change is invisible and it should stay\nso for performance reasons, not to harm the normal operation.\nIOW, I do not want the core level to even know about the\nexistence of \"permission information file\", even the code that\nimplements it is well isolated, ifdefed out or made conditional\nbased on some config variable.\n\nI however think your idea to have extra \"permission information\nfile\" is very interesting. What would be more palatable, than\nmucking with the core level git, would be to have an external\ncommand that takes two tree object names that tells it what the\nold and new trees our work tree is switching between, and have\nthat command to:\n\n - inspect the diff-tree output to find out what were checked\n out and might need their permission information tweaked;\n\n - inspect the differences between the \"permission information\n file\" in these trees to find out what were _not_ checked out,\n but still need their permission information tweaked.\n\n - tweak whatever external information you are interested in\n expressing in your \"permission information file\" in the work\n tree for the paths it discovered in the above two steps.\n This step may involve actions specific to projects and call\n hook scripts with tuples to carry out the actual tweaking.\n\nIf we go that route, I am not deeply opposed to add code to\nPorcelains to call that new command after they \"checkout\" a new\ncommit at the very end of their processing (namely, git-commit,\ngit-merge, git-am, and git-rebase).\n\nYes, I am very well aware that somebody already mentioned \"there\nis a window between the true checkout and permission tweaking\".\nIf you need to touch the core level in order to close that\nwindow, I am not interested.\n\n> The ability to handle /etc comes up every few months. it's got to be\n> the most common unimplemented request git has seen.\n\nAsking a pony for many times does not necessary make it the\nright for you to have the pony. The sane way to implement this\nis in your Makefile, as Randal and other people with more\nexperience have already pointed out, and I happen to agree with\nthem.\n\nMy gut feeling is that the approach to use an external hook that\nreads your \"permission information file\" could be done with\nnegligible impact to the normal operation of git. I suspect\nthat the \"new command\" I suggested above that would run after\n\"checkout\" actions would perform what people need to do in their\nMakefiles' \"install\" rules (if they have the work tree vs target\ntree distinction), or \"post-checkout\" rules (if they want to use\nthe work tree in-place), and not having to write/reinvent a\nMakefile target for this in every project would hopefully make\nit easier to use. That is the only reason I am writing this\nmessage on this topic.\n\n> so would changes like this be acceptable?\n\nThat is a different question. Is having an extention to help\npeople who want to manage perm bits a worthy goal? Perhaps, but\nit depends. Is it worthy enough goal to complicate the really\ncore parts of the code and add huge maintenance burden?\nAbsolutely not. Can it be made in such a way that it does not\nhave much impact to the core parts? We need to see how it is\ndone.\n"},{"id":"53177","messageId":"85zlzn812s.fsf@lola.goethe.zz","threadId":"9838","inReplyTo":"7vwsur590q.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-16T08:30:03Z","receivedAt":"2007-09-16T08:30:03Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Yes, I am very well aware that somebody already mentioned \"there\n> is a window between the true checkout and permission tweaking\".\n> If you need to touch the core level in order to close that\n> window, I am not interested.\n\nDoing this atomically involves creating the file in question by\nspecifying the permissions on the creat system call already, and\npossibly wrap seteuid calls and similar around it for getting the\nright file/ownership.\n\nHowever, it is not really necessary to do this atomically: instead one\ncan rather create the file using safe permissions (600) at first, then\ndo fchown and fchmod (or chown/chmod) at some point in time afterwards\nas required.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"53191","messageId":"Pine.LNX.4.64.0709161054380.5298@iabervon.org","threadId":"9838","inReplyTo":"7vwsur590q.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-09-16T15:51:06Z","receivedAt":"2007-09-16T15:51:06Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> I however think your idea to have extra \"permission information\n> file\" is very interesting. What would be more palatable, than\n> mucking with the core level git, would be to have an external\n> command that takes two tree object names that tells it what the\n> old and new trees our work tree is switching between, and have\n> that command to:\n> \n> - inspect the diff-tree output to find out what were checked\n> out and might need their permission information tweaked;\n> \n> - inspect the differences between the \"permission information\n> file\" in these trees to find out what were _not_ checked out,\n> but still need their permission information tweaked.\n> \n> - tweak whatever external information you are interested in\n> expressing in your \"permission information file\" in the work\n> tree for the paths it discovered in the above two steps.\n> This step may involve actions specific to projects and call\n> hook scripts with file\" for that path> tuples to carry out the actual tweaking.\n\nWhy not have the command also responsible for creating the files that need \nto be created (calling back into git to read their contents)? That way, \nthere's no window where they've been created without their metadata, and \nthere's more that the core git doesn't have to worry about.\n\nI could see the program getting the index, the target tree, and the \ndirectory to put files in, and being told to do the whole 2-way merge \n(except, perhaps, updating the index to match the tree, which git could do \nafterwards). As far as git would be concerned, it would mostly be like a \nbare repository.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"53192","messageId":"20070916155147.GA30476@efreet.light.src","threadId":"9838","inReplyTo":"20070916061411.GC24124@piper.oerlikon.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-16T15:51:47Z","receivedAt":"2007-09-16T15:51:47Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote:\n> also sprach Johannes Schindelin [2007.09.16.0014 +0200]:\n> > While at it, you should invent a fallback what to do when the\n> > owner is not present on the system you check out on. And\n> > a fallback when checking out on a filesystem that does not support\n> > owners.\n> \n> Like rsync, git would use numerical UIDs (which are always present)\n> by default, but could be told to try to map account names.\n> \n> If the filesystem does not support owners, chown() would not exist.\n> I actually tend to think of things the other way around: instead of\n> a fallback when chown() does not work (what would such a fallback be\n> other than not chown()ing?), it would only try chown() if such\n> functionality existed.\n\nThere's a problem. You need to know that the functionality is missing and not\ntry to read attributes back, but instead consider them unchanged. Nothing\nthat can't be taken care of, but it needs to be handled carefuly.\n\n> > And a fallback when a non-root user uses it.\n> \n> That's easy, Unix already provides you with that \"fallback\": pack up\n> /etc in a tar and unpack it as a normal user...\n\nBut if you tar that up again, the owners will be different. But you don't\nwant the change.\n\n> > Oh, and while you're at it (you said that it would be nice not to\n> > restrict git in any way: \"it is a content tracker\") support the\n> > Windows style \"Group-or-User-or-something:[FRW]\" ACLs.\n> \n> Provided we find a way to implement this in an extensible manner,\n> this should not be hard to do. I can't do it since I don't have\n> access to a Windows machine.\n> \n> Your statement does catch me off-guard though. Does git now\n> officially target Windows?\n\nOfficial git works in cygwin. There is also a port to msys, which is\nnot official in a sense it is not merged into mainline.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"53193","messageId":"20070916155913.GB30476@efreet.light.src","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709151737400.24221@asgard.lang.hm","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-16T15:59:13Z","receivedAt":"2007-09-16T15:59:13Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Sep 15, 2007 at 18:30:53 -0700, david@lang.hm wrote:\n> 1. whatever is trying to write the files with the correct permissions\n> needs to be able to query the permission store before files are\n> written. This needs to either be an API call into git to retreive the\n> information for any file when it's written, or the ability to define a\n> specific file to be checked out first so that it can be used for\n> everything else.\n\nYou seem to be forgetting about the index. Git never writes trees directly to\nfilesystem, but always with intermediate step in the index. So the API\nactually exists -- simply read from the index.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"53209","messageId":"Pine.LNX.4.64.0709161242170.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"20070916155147.GA30476@efreet.light.src","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T19:43:47Z","receivedAt":"2007-09-16T19:43:47Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Jan Hudec wrote:\n\n> On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote:\n>> also sprach Johannes Schindelin [2007.09.16.0014 +0200]:\n>>> While at it, you should invent a fallback what to do when the\n>>> owner is not present on the system you check out on. And\n>>> a fallback when checking out on a filesystem that does not support\n>>> owners.\n>>\n>> Like rsync, git would use numerical UIDs (which are always present)\n>> by default, but could be told to try to map account names.\n>>\n>> If the filesystem does not support owners, chown() would not exist.\n>> I actually tend to think of things the other way around: instead of\n>> a fallback when chown() does not work (what would such a fallback be\n>> other than not chown()ing?), it would only try chown() if such\n>> functionality existed.\n>\n> There's a problem. You need to know that the functionality is missing and not\n> try to read attributes back, but instead consider them unchanged. Nothing\n> that can't be taken care of, but it needs to be handled carefuly.\n\nbut this can be handled by a local config option. yes, you have to be \ncareful, but it'snot that hard.\n\nDavid Lang\n"},{"id":"53213","messageId":"Pine.LNX.4.64.0709161316310.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"85zlzn812s.fsf@lola.goethe.zz","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T20:19:31Z","receivedAt":"2007-09-16T20:19:31Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, David Kastrup wrote:\n\n> Junio C Hamano writes:\n>\n>> Yes, I am very well aware that somebody already mentioned \"there\n>> is a window between the true checkout and permission tweaking\".\n>> If you need to touch the core level in order to close that\n>> window, I am not interested.\n>\n> Doing this atomically involves creating the file in question by\n> specifying the permissions on the creat system call already, and\n> possibly wrap seteuid calls and similar around it for getting the\n> right file/ownership.\n>\n> However, it is not really necessary to do this atomically: instead one\n> can rather create the file using safe permissions (600) at first, then\n> do fchown and fchmod (or chown/chmod) at some point in time afterwards\n> as required.\n\nthe problem with this in /etc is if you do the wrong file as 600 you can \ncause lots of nasty problems to the system during the window. for some \nfiles/directories you will want to write the file to a temp name and then \nmove the file atomicly to the final location.\n\ngit itself shouldn't need to worry about this, the external write routine \nI'm talking about is the correct place for this (at least until all the \nbugs get worked out and everyone is comfortable that everything is good, \nand doesn't impact the core git code badly)\n\nDavid Lang\n"},{"id":"53215","messageId":"Pine.LNX.4.64.0709161321360.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"20070916155913.GB30476@efreet.light.src","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T20:36:08Z","receivedAt":"2007-09-16T20:36:08Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Jan Hudec wrote:\n\n> On Sat, Sep 15, 2007 at 18:30:53 -0700, david@lang.hm wrote:\n>> 1. whatever is trying to write the files with the correct permissions\n>> needs to be able to query the permission store before files are\n>> written. This needs to either be an API call into git to retreive the\n>> information for any file when it's written, or the ability to define a\n>> specific file to be checked out first so that it can be used for\n>> everything else.\n>\n> You seem to be forgetting about the index. Git never writes trees directly to\n> filesystem, but always with intermediate step in the index. So the API\n> actually exists -- simply read from the index.\n\nOk, this sounds promising.\n\nlooking into one approach here.\n\nassume for the moment that at write time an external program gets called.\n\nthis program reads the file contents from stdin and gets it's other \ninformation from git as command line parameters\n parameters I can think it would need are\n path to write the file to\n length of file\n name of the permission file\n id of the commit this is part of (possibly)\n\nhow does this program access the contents of the permission file in the \nindex?\n\nDavid Lang\n"},{"id":"53217","messageId":"Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161054380.5298@iabervon.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T21:12:23Z","receivedAt":"2007-09-16T21:12:23Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Daniel Barkalow wrote:\n\n>> I however think your idea to have extra \"permission information\n>> file\" is very interesting. What would be more palatable, than\n>> mucking with the core level git, would be to have an external\n>> command that takes two tree object names that tells it what the\n>> old and new trees our work tree is switching between, and have\n>> that command to:\n>>\n>> - inspect the diff-tree output to find out what were checked\n>> out and might need their permission information tweaked;\n>>\n>> - inspect the differences between the \"permission information\n>> file\" in these trees to find out what were _not_ checked out,\n>> but still need their permission information tweaked.\n>>\n>> - tweak whatever external information you are interested in\n>> expressing in your \"permission information file\" in the work\n>> tree for the paths it discovered in the above two steps.\n>> This step may involve actions specific to projects and call\n>> hook scripts with > file\" for that path> tuples to carry out the actual tweaking.\n>\n> Why not have the command also responsible for creating the files that need\n> to be created (calling back into git to read their contents)? That way,\n> there's no window where they've been created without their metadata, and\n> there's more that the core git doesn't have to worry about.\n\nmy initial thoughts were to have git do all it's normal work and hook into \ngit at the point where it's writing the file out (where today it chooses \nbetween writing the data to a file on disk, pipeing to stdout, or pipeing \nto a pager) by adding the option to pipe into a different program that \nwould deal with the permission stuff. this program would only have to \nwrite the file and set the permissions, it wouldn't have to know anything \nabout git other then where to find the permissions it needs to know.\n\nit sounds like you are suggesting that the hook be much earlier in the \nprocess, and instead of one copy of git running and calling many copies of \nthe writing program, you would have one copy of the writing program that \nwould call many copies of git.\n\nI'll admit that my initial reaction is that it's probably a lot more \nexpensive to do all the calls into git. git just has a lot more complex \nthings to do.\n\n> I could see the program getting the index, the target tree, and the\n> directory to put files in, and being told to do the whole 2-way merge\n> (except, perhaps, updating the index to match the tree, which git could do\n> afterwards). As far as git would be concerned, it would mostly be like a\n> bare repository.\n\nif this functionality does shift to earlier in the process, how much of \nthe git logic needs to be duplicated in this program?\n\nif this program needs to do the merge, won't it have to duplicate the \nmerge logic, including the .gitattributes checking for custom merge calls?\n\n\nI have been thinking primarily in terms of doing a complete checkout, \noverwriting all files, and secondarily how do do a checkout of just a few \nfiles, but again where all files selected overwrite the existing files.\n\nI wasn't thinking of the fact that git optimizes the checkout and avoids \nwriting a file that didn't change.\n\nthis changes things slightly\n\nprior to this I was thinking that the permission file needed to be handled \ndifferently becouse writing it out needed to avoid doing any circular \nrefrences where you would need to check the contents of it to write it \nout.\n\nit now appears as if what really needs to happen is that if the permission \nfile changes a different program needs to be called when it's written out \nthen when the other files are written out. by itself this isn't hard as \n.gitattributes can have a special entry for this filename and that entry \ncan specify a different program, and that program fixes all the \npermissions (and/or detects that they can't be fixed due to \nuser/filesystem limits, records the error, checks if the repository is set \nappropriately, and screams to the user if it isn't)\n\nit would be a nice optimization to this permission checkout for it to \ncompare the old and the new permissions so that it only tries to change \nthe permissions where it needs to, but is that really nessasary? the \nprogram can look at the permissions of the existing files to see what they \nare and decide if it needs to change them (this would tromp on local \nchanges that aren't checked in. how big of a problem is this?) my initial \nreaction is that having to know the two commits and do the comparison \nbetween them is adding a lot of logic and git interaction that I'd rather \navoid if I could.\n\nDavid Lang\n"},{"id":"53219","messageId":"7vbqc25mgi.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-16T21:28:45Z","receivedAt":"2007-09-16T21:28:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> my initial thoughts were to have git do all it's normal work and hook\n> into git at the point where it's writing the file out (where today it\n> chooses between writing the data to a file on disk, pipeing to stdout,\n> or pipeing to a pager) by adding the option to pipe into a different\n> program that would deal with the permission stuff. this program would\n> only have to write the file and set the permissions, it wouldn't have\n> to know anything about git other then where to find the permissions it\n> needs to know.\n>\n> it sounds like you are suggesting that the hook be much earlier in the\n> process,...\n\nWell, you misread me or what I said was confusing or both. I\nwas suggesting totally opposite. Let git do all its normal\nwork, and then call your hook to munge the work tree in any way\nyou want.\n"},{"id":"53225","messageId":"Pine.LNX.4.64.0709161245490.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"7vwsur590q.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T21:45:25Z","receivedAt":"2007-09-16T21:45:25Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"some of this duplicates thoughts from other messages in this thread. \napologies for the duplication, but I want to be clear the response to \nJunio's concerns here as well\n\nOn Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n>\n>> git has pre-commit hooks that could be used to gather the permission\n>> information and store it into a file.\n>>\n>> git now has the ability to define cusom merge strategies for specific\n>> file types, which could be used to handle merges for the permission\n>> files.\n>> ...\n>> There are some significant advantages of having the permission store\n>> be just a text file.\n>>\n>> 1. it doesn't require a special API to a new datastore in git\n>>\n>> 2. when working in an environment that doesn't allow for implementing the\n>> permissions (either a filesystem that can't store the permissions or\n>> when not working as root so that you can't set the ownership) the file\n>> can just be written and then edited with normal tools.\n>>\n>> 3. normal merge tools do a reasonable job of merging them.\n>>\n>> however to do this git would need to gain the ability to say 'this\n>> filename is special, it must be checked out before any other file is\n>> checked out' (either on a per-directory or per-repository level)\n>\n> I'd rather not implement it at such a low level where a true\n> \"checkout\" happens. For one thing, I am afraid that the special\n> casing will affect the normal codepath too much and would make\n> it into a maintenance nightmare.\n\nas I understand it, at this point you already choose between three \noptions.\n\n1. write to a file (and set the write bit if needed)\n2. write to stdout\n3. write to a pager program\n\nI am suggesting adding\n\n4. write to a .gitattributes defined program and pass it some parameters.\n (and only if the .gitattributes tell you to)\n\nthis should be a very small change to the codepath\n\nor am I missing something major here?\n\nif this program can get the contents of the permission file out of the \nindex, then the requirement I listed before to make sure the permission \nfile gets written before anything else goes away, and the only requirement \nleft is the ability to specify a different write method\n\n> But more importantly, if you\n> are switching between commits (this includes switching branches,\n> checking out a different commit to a detached HEAD, or\n> pulling/merging updates your HEAD and updates your work tree),\n> and the contents of a path does not change between the original\n> commit and the switched-to commit, you may still have to\n> \"checkout\" the external information for that path if your\n> \"permission information file\" are different between these two\n> commits. To the underlying checkout aka \"two tree merge\"\n> operation, that kind of change is invisible and it should stay\n> so for performance reasons, not to harm the normal operation.\n\nI had not thought of this condition.\n\nhowever, I think this may be easier then you are thinking\n\nwe have two conditions.\n\n1. the permission file hasn't changed.\n\nSolution: do nothing\n\n2. the permission file has changed\n\nSolution: set all the permissions to match the new file\n\nthis could be done by useing .gitattributes to specify a different program \nfor checking out the permission file, and that program goes through the \nfile and sets the permssions on everything. yes this is a bit inefficiant \ncompared to diffing the two permission files and only touching the files \nthat have changed, but is the efficiancy at this point that critical? if \nso then instead of feeding the program the contents of the new file you \ncould feed it the diff between the old and the new file.\n\nin theory you could do this for any file, and it would be a win for some \nfiles (a large file that has a few changes to it would possibly be more \nefficiant to modify in place then to re-write), but I'm not sure the \nresults would be worth the complications. if .gitattributes gains the \nability to specify the program to be used to write the file, it could also \ngain the ability to specify feeding that file the diff instead of the full \ncontents.\n\nthe one drawback to just setting all the permissions is that this will \noverrule any local changes to files that weren't otherwise modified. how \nbig of a problem is this?\n\n> IOW, I do not want the core level to even know about the\n> existence of \"permission information file\", even the code that\n> implements it is well isolated, ifdefed out or made conditional\n> based on some config variable.\n\nnobody is suggesting anything that wouldn't be at least conditional based \non some config variable.\n\n> I however think your idea to have extra \"permission information\n> file\" is very interesting. What would be more palatable, than\n> mucking with the core level git, would be to have an external\n> command that takes two tree object names that tells it what the\n> old and new trees our work tree is switching between, and have\n> that command to:\n>\n> - inspect the diff-tree output to find out what were checked\n> out and might need their permission information tweaked;\n>\n> - inspect the differences between the \"permission information\n> file\" in these trees to find out what were _not_ checked out,\n> but still need their permission information tweaked.\n>\n> - tweak whatever external information you are interested in\n> expressing in your \"permission information file\" in the work\n> tree for the paths it discovered in the above two steps.\n> This step may involve actions specific to projects and call\n> hook scripts with file\" for that path> tuples to carry out the actual tweaking.\n\nthis is an area I wasn't aware of, but it doesn't seem that difficult to \ndo. the issue (as I address above) is if this needs to be done as a diff \nor if it can be done simply by setting all the permissions according to \nthe new file.\n\n> If we go that route, I am not deeply opposed to add code to\n> Porcelains to call that new command after they \"checkout\" a new\n> commit at the very end of their processing (namely, git-commit,\n> git-merge, git-am, and git-rebase).\n\nthis is saying you want a wrapper around git instead of a hook in git.\n\n> Yes, I am very well aware that somebody already mentioned \"there\n> is a window between the true checkout and permission tweaking\".\n> If you need to touch the core level in order to close that\n> window, I am not interested.\n\nno matter how small the change? (see the above comments) If so this \nconverstion isn't worth continuing, if you are just concerned about \nmaintainability and are willing to consider small changes that won't cause \nbig maintinance problems then we can continue to discuss if the changes I \nam suggesting are small enough. the need to be able to close the \nvunerability window is a showstopper to many uses.\n\n>> The ability to handle /etc comes up every few months. it's got to be\n>> the most common unimplemented request git has seen.\n>\n> Asking a pony for many times does not necessary make it the\n> right for you to have the pony. The sane way to implement this\n> is in your Makefile, as Randal and other people with more\n> experience have already pointed out, and I happen to agree with\n> them.\n\nyou don't always have a makefile. if other tools that you use make \nmodifications to the files in the locations where they reside, having to \npull those changes back before you can do a checking is a complication as \nwell\n\n> My gut feeling is that the approach to use an external hook that\n> reads your \"permission information file\" could be done with\n> negligible impact to the normal operation of git. I suspect\n> that the \"new command\" I suggested above that would run after\n> \"checkout\" actions would perform what people need to do in their\n> Makefiles' \"install\" rules (if they have the work tree vs target\n> tree distinction), or \"post-checkout\" rules (if they want to use\n> the work tree in-place), and not having to write/reinvent a\n> Makefile target for this in every project would hopefully make\n> it easier to use. That is the only reason I am writing this\n> message on this topic.\n\nbut you are not willing to allow the hook to be created, you are saying \nthat there would need to be an external wrapper instead.\n\nat this point it appears that having a hook to be able to specify external \nprograms at a point where you are already deciding between different \noptions would be sufficiant.\n\n>> so would changes like this be acceptable?\n>\n> That is a different question. Is having an extention to help\n> people who want to manage perm bits a worthy goal? Perhaps, but\n> it depends. Is it worthy enough goal to complicate the really\n> core parts of the code and add huge maintenance burden?\n> Absolutely not. Can it be made in such a way that it does not\n> have much impact to the core parts? We need to see how it is\n> done.\n\nthis is why I was asking about this approach. do changes like this seem \nsmall enough to be worth the effort of coding and submitting?\n\nDavid Lang\n"},{"id":"53224","messageId":"Pine.LNX.4.64.0709161731490.5298@iabervon.org","threadId":"9838","inReplyTo":"7vbqc25mgi.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-09-16T21:45:43Z","receivedAt":"2007-09-16T21:45:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n> \n> > my initial thoughts were to have git do all it's normal work and hook\n> > into git at the point where it's writing the file out (where today it\n> > chooses between writing the data to a file on disk, pipeing to stdout,\n> > or pipeing to a pager) by adding the option to pipe into a different\n> > program that would deal with the permission stuff. this program would\n> > only have to write the file and set the permissions, it wouldn't have\n> > to know anything about git other then where to find the permissions it\n> > needs to know.\n> >\n> > it sounds like you are suggesting that the hook be much earlier in the\n> > process,...\n> \n> Well, you misread me or what I said was confusing or both. I\n> was suggesting totally opposite. Let git do all its normal\n> work, and then call your hook to munge the work tree in any way\n> you want.\n\nI think he was replying to me, not you. I was suggesting that git stop at \nthe index, and let him take care of deciding how the index relates to the \nwork tree. That is, he'd get called instead of check_updates() in \nunpack-trees. (And we might have to funnel more code paths through this \nfunction, so that checkout-index does what read-tree -m would do, wrt \nchanges to the filesystem).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"53226","messageId":"Pine.LNX.4.64.0709161445380.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"7vbqc25mgi.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T21:53:46Z","receivedAt":"2007-09-16T21:53:46Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n>\n>> my initial thoughts were to have git do all it's normal work and hook\n>> into git at the point where it's writing the file out (where today it\n>> chooses between writing the data to a file on disk, pipeing to stdout,\n>> or pipeing to a pager) by adding the option to pipe into a different\n>> program that would deal with the permission stuff. this program would\n>> only have to write the file and set the permissions, it wouldn't have\n>> to know anything about git other then where to find the permissions it\n>> needs to know.\n>>\n>> it sounds like you are suggesting that the hook be much earlier in the\n>> process,...\n>\n> Well, you misread me or what I said was confusing or both. I\n> was suggesting totally opposite. Let git do all its normal\n> work, and then call your hook to munge the work tree in any way\n> you want.\n\nso you are saying, have git write everything out as-is and then call a \nprogram afterwords to do things? essentially a post-checkout hook?\n\nsuch a hook is useful in many situations, and would allow for the workflow \nwhere you have /etc, /etc.git, and write scripts to move things back and \nforth between them.\n\nso I do think that this is a capability that would be useful to git \noverall.\n\nhowever, for the specific use-case of maintaining /etc I don't think that \nit's as good as having a hook at write time.\n\nDavid Lang\n"},{"id":"53227","messageId":"Pine.LNX.4.64.0709161715090.5298@iabervon.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-09-16T22:02:43Z","receivedAt":"2007-09-16T22:02:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Sep 2007, david@lang.hm wrote:\n\n> On Sun, 16 Sep 2007, Daniel Barkalow wrote:\n> \n> > > I however think your idea to have extra \"permission information\n> > > file\" is very interesting. What would be more palatable, than\n> > > mucking with the core level git, would be to have an external\n> > > command that takes two tree object names that tells it what the\n> > > old and new trees our work tree is switching between, and have\n> > > that command to:\n> > >\n> > > - inspect the diff-tree output to find out what were checked\n> > > out and might need their permission information tweaked;\n> > >\n> > > - inspect the differences between the \"permission information\n> > > file\" in these trees to find out what were _not_ checked out,\n> > > but still need their permission information tweaked.\n> > >\n> > > - tweak whatever external information you are interested in\n> > > expressing in your \"permission information file\" in the work\n> > > tree for the paths it discovered in the above two steps.\n> > > This step may involve actions specific to projects and call\n> > > hook scripts with > > file\" for that path> tuples to carry out the actual tweaking.\n> >\n> > Why not have the command also responsible for creating the files that need\n> > to be created (calling back into git to read their contents)? That way,\n> > there's no window where they've been created without their metadata, and\n> > there's more that the core git doesn't have to worry about.\n> \n> my initial thoughts were to have git do all it's normal work and hook into git\n> at the point where it's writing the file out (where today it chooses between\n> writing the data to a file on disk, pipeing to stdout, or pipeing to a pager)\n> by adding the option to pipe into a different program that would deal with the\n> permission stuff. this program would only have to write the file and set the\n> permissions, it wouldn't have to know anything about git other then where to\n> find the permissions it needs to know.\n> \n> it sounds like you are suggesting that the hook be much earlier in the\n> process, and instead of one copy of git running and calling many copies of the\n> writing program, you would have one copy of the writing program that would\n> call many copies of git.\n\nA lot of the git commands are actually currently shell scripts that call \nback to git, so that's not too different. The reason to have a single copy \nof the writing program is that it would be able to get the whole set of \ndifferences that need to be handled, and first pick out the metadata file, \nprocess it to figure out the writing instructions once, figure out the \nchanges in the writing instructions, and figure out the changes in the \ncontent, and decide what to do.\n\n> > I could see the program getting the index, the target tree, and the\n> > directory to put files in, and being told to do the whole 2-way merge\n> > (except, perhaps, updating the index to match the tree, which git could do\n> > afterwards). As far as git would be concerned, it would mostly be like a\n> > bare repository.\n> \n> if this functionality does shift to earlier in the process, how much of the\n> git logic needs to be duplicated in this program?\n> \n> if this program needs to do the merge, won't it have to duplicate the merge\n> logic, including the .gitattributes checking for custom merge calls?\n\nThis is two-way merge, not three-way merge. The basic concept is that \nyou're in state A, and you want to be in state B. Rather than writing out \nall of state B, you write out all of state B that's different from state \nA. Think of taking a diff of two big trees and then applying it as a \npatch, instead of copying the new tree onto the old tree; the benefit is \nthat stuff that doesn't change doesn't get rewritten, and the diff is \nblazingly fast, given how we store our information.\n\n3-way merge will be handled by git, and not in a live /etc directory \nanyway (that is, you'd want to fix up the metadata files as plain text \nfiles, not as metadata bits on a checked out directory; otherwise, you'll \nbe trying to put conflict markers in mode bits, and that's clearly not \nwhat you want).\n\n> I have been thinking primarily in terms of doing a complete checkout,\n> overwriting all files, and secondarily how do do a checkout of just a few\n> files, but again where all files selected overwrite the existing files.\n> \n> I wasn't thinking of the fact that git optimizes the checkout and avoids\n> writing a file that didn't change.\n> \n> this changes things slightly\n> \n> prior to this I was thinking that the permission file needed to be handled\n> differently becouse writing it out needed to avoid doing any circular\n> refrences where you would need to check the contents of it to write it out.\n> \n> it now appears as if what really needs to happen is that if the permission\n> file changes a different program needs to be called when it's written out then\n> when the other files are written out. by itself this isn't hard as\n> .gitattributes can have a special entry for this filename and that entry can\n> specify a different program, and that program fixes all the permissions\n> (and/or detects that they can't be fixed due to user/filesystem limits,\n> records the error, checks if the repository is set appropriately, and screams\n> to the user if it isn't)\n\nWhile we're at it, you probably don't even want to write the permission \nfile to the live filesystem. It's just one more thing that could leak \ninformation, and changes to the permissions of files that you record by \ncommitting the live filesystem would presumably be done by changing the \npermissions of files in the filesystem, not by changing the text file.\n\n(Of course, you could check out the same commits as ordinary source, with \ndeveloper-owned 644 files and a 644 \"permissions\" file, and there you'd \nhave the permissions file appear in the work tree, and you could edit it \nand check it in in a totally mundane way.)\n\n> it would be a nice optimization to this permission checkout for it to compare\n> the old and the new permissions so that it only tries to change the\n> permissions where it needs to, but is that really nessasary? the program can\n> look at the permissions of the existing files to see what they are and decide\n> if it needs to change them (this would tromp on local changes that aren't\n> checked in. how big of a problem is this?) my initial reaction is that having\n> to know the two commits and do the comparison between them is adding a lot of\n> logic and git interaction that I'd rather avoid if I could.\n\nYou probably want to be able to keep local uncommitted changes. People \nlike to be able to have things slightly different in their particular \ndeployment from the way things are in the repository, for stuff that only \napplies to one system and isn't \"how it should be\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"53228","messageId":"7v7imq5ki0.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161245490.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-16T22:11:03Z","receivedAt":"2007-09-16T22:11:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n>> I'd rather not implement it at such a low level where a true\n>> \"checkout\" happens. For one thing, I am afraid that the special\n>> casing will affect the normal codepath too much and would make\n>> it into a maintenance nightmare.\n>\n> as I understand it, at this point you already choose between three\n> options.\n>\n> 1. write to a file (and set the write bit if needed)\n> 2. write to stdout\n> 3. write to a pager program\n>\n> I am suggesting adding\n> ...\n> or am I missing something major here?\n\nI do not think we are choosing any option in the codepath at\nall.\n\nWhat I mean by the normal \"checkout\" is what checkout_entry in\nentry.c does. There is no other option than (1) above. I would\nwant to see an extremely good justification if you need to touch\nthat codepath to implement this fringe use case.\n\nI do not think there is nothing that writes file contents to\nstdout/pager other than \"git cat-file\" or \"git show\"; I do not\nthink they are what you have in mind when talking about managing\nthe files under /etc. So unfortunately I do not understand the\nrest of the discussion you made in your message.\n"},{"id":"53229","messageId":"Pine.LNX.4.64.0709161507130.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161715090.5298@iabervon.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T22:37:45Z","receivedAt":"2007-09-16T22:37:45Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Daniel Barkalow wrote:\n\n> On Sun, 16 Sep 2007, david@lang.hm wrote:\n>\n>> On Sun, 16 Sep 2007, Daniel Barkalow wrote:\n>>\n>>>> I however think your idea to have extra \"permission information\n>>>> file\" is very interesting. What would be more palatable, than\n>>>> mucking with the core level git, would be to have an external\n>>>> command that takes two tree object names that tells it what the\n>>>> old and new trees our work tree is switching between, and have\n>>>> that command to:\n>>>>\n>>>> - inspect the diff-tree output to find out what were checked\n>>>> out and might need their permission information tweaked;\n>>>>\n>>>> - inspect the differences between the \"permission information\n>>>> file\" in these trees to find out what were _not_ checked out,\n>>>> but still need their permission information tweaked.\n>>>>\n>>>> - tweak whatever external information you are interested in\n>>>> expressing in your \"permission information file\" in the work\n>>>> tree for the paths it discovered in the above two steps.\n>>>> This step may involve actions specific to projects and call\n>>>> hook scripts with >>> file\" for that path> tuples to carry out the actual tweaking.\n>>>\n>>> Why not have the command also responsible for creating the files that need\n>>> to be created (calling back into git to read their contents)? That way,\n>>> there's no window where they've been created without their metadata, and\n>>> there's more that the core git doesn't have to worry about.\n>>\n>> my initial thoughts were to have git do all it's normal work and hook into git\n>> at the point where it's writing the file out (where today it chooses between\n>> writing the data to a file on disk, pipeing to stdout, or pipeing to a pager)\n>> by adding the option to pipe into a different program that would deal with the\n>> permission stuff. this program would only have to write the file and set the\n>> permissions, it wouldn't have to know anything about git other then where to\n>> find the permissions it needs to know.\n>>\n>> it sounds like you are suggesting that the hook be much earlier in the\n>> process, and instead of one copy of git running and calling many copies of the\n>> writing program, you would have one copy of the writing program that would\n>> call many copies of git.\n>\n> A lot of the git commands are actually currently shell scripts that call\n> back to git, so that's not too different. The reason to have a single copy\n> of the writing program is that it would be able to get the whole set of\n> differences that need to be handled, and first pick out the metadata file,\n> process it to figure out the writing instructions once, figure out the\n> changes in the writing instructions, and figure out the changes in the\n> content, and decide what to do.\n\nI'm still a little unclear on how much work this program would then have \nto do. it's problably my lack of understanding that's makeing this sound \nmuch scarier.\n\n>>> I could see the program getting the index, the target tree, and the\n>>> directory to put files in, and being told to do the whole 2-way merge\n>>> (except, perhaps, updating the index to match the tree, which git could do\n>>> afterwards). As far as git would be concerned, it would mostly be like a\n>>> bare repository.\n>>\n>> if this functionality does shift to earlier in the process, how much of the\n>> git logic needs to be duplicated in this program?\n>>\n>> if this program needs to do the merge, won't it have to duplicate the merge\n>> logic, including the .gitattributes checking for custom merge calls?\n>\n> This is two-way merge, not three-way merge. The basic concept is that\n> you're in state A, and you want to be in state B. Rather than writing out\n> all of state B, you write out all of state B that's different from state\n> A. Think of taking a diff of two big trees and then applying it as a\n> patch, instead of copying the new tree onto the old tree; the benefit is\n> that stuff that doesn't change doesn't get rewritten, and the diff is\n> blazingly fast, given how we store our information.\n\nso what would this program be given?\n\nit sounds like it would be called once for the entire tree checkout\n\nwould it be handed just the start and end commits and query git for \neverything else it needs?\n\nit sounds like there is more then this, you refer to git fully crafting \nthe new index.\n\nso would this program be accessing an old and new index and do the \ncomparison between the two?\n\nor would git feed it a list of what's changed and then have it query git \nto find the details of the changes.\n\n> 3-way merge will be handled by git, and not in a live /etc directory\n> anyway (that is, you'd want to fix up the metadata files as plain text\n> files, not as metadata bits on a checked out directory; otherwise, you'll\n> be trying to put conflict markers in mode bits, and that's clearly not\n> what you want).\n\nright, we don't want conflict markers on mode bits or other ACL type \nthings, that way lies madness ;)\n\n>> I have been thinking primarily in terms of doing a complete checkout,\n>> overwriting all files, and secondarily how do do a checkout of just a few\n>> files, but again where all files selected overwrite the existing files.\n>>\n>> I wasn't thinking of the fact that git optimizes the checkout and avoids\n>> writing a file that didn't change.\n>>\n>> this changes things slightly\n>>\n>> prior to this I was thinking that the permission file needed to be handled\n>> differently becouse writing it out needed to avoid doing any circular\n>> refrences where you would need to check the contents of it to write it out.\n>>\n>> it now appears as if what really needs to happen is that if the permission\n>> file changes a different program needs to be called when it's written out then\n>> when the other files are written out. by itself this isn't hard as\n>> .gitattributes can have a special entry for this filename and that entry can\n>> specify a different program, and that program fixes all the permissions\n>> (and/or detects that they can't be fixed due to user/filesystem limits,\n>> records the error, checks if the repository is set appropriately, and screams\n>> to the user if it isn't)\n>\n> While we're at it, you probably don't even want to write the permission\n> file to the live filesystem. It's just one more thing that could leak\n> information, and changes to the permissions of files that you record by\n> committing the live filesystem would presumably be done by changing the\n> permissions of files in the filesystem, not by changing the text file.\n\nthe permissions and ACL's can be queried directly from the filesystem, so \nI don't see any security problems with writing the permission file to the \nfilesystem.\n\nchanging the permissions would be done by changing the files themselves \n(when you are running as root on a filesystem that supports the changes, \notherwise it would need to fall back to writing the file and getting the \nchanges there, but that should be able to be a local config option)\n\nI don't like the idea of having a file that doesn't appear on the local \nfilesystem at any point, it just makes troubleshooting too hard.\n\n> (Of course, you could check out the same commits as ordinary source, with\n> developer-owned 644 files and a 644 \"permissions\" file, and there you'd\n> have the permissions file appear in the work tree, and you could edit it\n> and check it in in a totally mundane way.)\n\nright, and the same thing if the filesystem doesn't support something in \nthe permission file.\n\n>> it would be a nice optimization to this permission checkout for it to compare\n>> the old and the new permissions so that it only tries to change the\n>> permissions where it needs to, but is that really nessasary? the program can\n>> look at the permissions of the existing files to see what they are and decide\n>> if it needs to change them (this would tromp on local changes that aren't\n>> checked in. how big of a problem is this?) my initial reaction is that having\n>> to know the two commits and do the comparison between them is adding a lot of\n>> logic and git interaction that I'd rather avoid if I could.\n>\n> You probably want to be able to keep local uncommitted changes. People\n> like to be able to have things slightly different in their particular\n> deployment from the way things are in the repository, for stuff that only\n> applies to one system and isn't \"how it should be\".\n\nif so this means that the permission changing program definantly needs to \noperate on the diff of the permisison file, not on the absolute file. this \ncomplicates things slightly, but it shouldn't be too bad.\n\nchanging topic slightly.\n\nI know git has pre-commit hooks, but I've never needed to use them.\n\nat what point can you hook in?\n\ncan you define a hook that runs when you do a git-add? or only when you do \na git-commit?\n\nthe reason I'm asking is to try and figure out when and how to create the \npermissions file. when I was thinking in terms of dealing with the \npermissions as a single bog block it wasn't that bad to say that at \ngit-commit time you have to scan every file and check it's permissions to \nrecord them into the file, but with the push for the optimizations that \nyou're talking about this is no longer reasonable and it really should be \ndone when the file is added to the index.\n\non a related note, if this is implemented as a per-write hook then it \nmakes a lot of sense to have the permission file be per-directory, but if \nwe do a per-checkout hook like you are suggesting then the permission file \nmay make more sense as a single file in the top-level directory.\n\nthoughts?\n\nDavid Lang\n"},{"id":"53235","messageId":"Pine.LNX.4.64.0709161541330.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"7v7imq5ki0.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-16T22:52:23Z","receivedAt":"2007-09-16T22:52:23Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n>\n>>> I'd rather not implement it at such a low level where a true\n>>> \"checkout\" happens. For one thing, I am afraid that the special\n>>> casing will affect the normal codepath too much and would make\n>>> it into a maintenance nightmare.\n>>\n>> as I understand it, at this point you already choose between three\n>> options.\n>>\n>> 1. write to a file (and set the write bit if needed)\n>> 2. write to stdout\n>> 3. write to a pager program\n>>\n>> I am suggesting adding\n>> ...\n>> or am I missing something major here?\n>\n> I do not think we are choosing any option in the codepath at\n> all.\n>\n> What I mean by the normal \"checkout\" is what checkout_entry in\n> entry.c does. There is no other option than (1) above. I would\n> want to see an extremely good justification if you need to touch\n> that codepath to implement this fringe use case.\n>\n> I do not think there is nothing that writes file contents to\n> stdout/pager other than \"git cat-file\" or \"git show\"; I do not\n> think they are what you have in mind when talking about managing\n> the files under /etc. So unfortunately I do not understand the\n> rest of the discussion you made in your message.\n\nOk, I thought that there was common code for these different uses. could \nyou re-read the rest of the logic based on the change being done in \ncheckout_entry?\n\nif you are unwilling to have any changes made to the checkout_entry code \nthen the only remaing question is what you think of Daniel's suggestion to \nhave a hook to replace check_updates()?\n\nif it's not acceptable either then we are down to doing a post-checkout \ntrigger.\n\none concern I have with that approach is how to deal with partial \ncheckouts. if a user checks out one file how can the post-checkout trigger \nknow if it's looking at the correct permissions file as opposed to one \nleft over from something else? can/should it go and read the file from the \nindex instead of reading the file on the filesystem? (I don't like this \nbecouse it leads to non-obvious behavior), or can/should there be a config \noption to say that whenever any file is checked out the permissions file \nneeds to be checked out as well.\n\na post checkout trigger is useful in enough different situations that the \nanswers to the above questions don't eliminate the usefulness of the \ntrigger, they just map out the pitfalls of useing it.\n\nDavid Lang\n"},{"id":"53243","messageId":"7vk5qq3y76.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161541330.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-17T00:58:05Z","receivedAt":"2007-09-17T00:58:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> On Sun, 16 Sep 2007, Junio C Hamano wrote:\n>>\n>> I do not think there is nothing that writes file contents to\n>> stdout/pager other than \"git cat-file\" or \"git show\"; I do not\n>> think they are what you have in mind when talking about managing\n>> the files under /etc. So unfortunately I do not understand the\n>> rest of the discussion you made in your message.\n>\n> Ok, I thought that there was common code for these different\n> uses. could you re-read the rest of the logic based on the change\n> being done in checkout_entry?\n>\n> if you are unwilling to have any changes made to the checkout_entry\n> code then the only remaing question is what you think of Daniel's\n> suggestion to have a hook to replace check_updates()?\n>\n> if it's not acceptable either then we are down to doing a\n> post-checkout trigger.\n\nPost-checkout trigger is something I can say I can live with\nwithout looking at the actual patch, but that does not mean it\nwould be a better approach at all.\n\nI would not be able to answer the first question right now; that\nneeds a patch to prove that it can be done with a well contained\nset of changes that results in a maintainable code.\n\nI haven't tried to assess the potential extent of damage needed\nto checkout_entry(), and I have never been interested in this\n\"keeping track of /etc in place\" topic myself. It is unlikely\nI'll try to come up with such a patch on my own to support it at\nsuch a low level near the core. Somebody who cares about that\nfeature needs to take the initiative of doing that work before\nwe can discuss and decide, although older-times including myself\ncan help spot potential issues.\n\nSo while I admit I am skeptical, consider me neither willing nor\nunwilling at this point.\n"},{"id":"53244","messageId":"Pine.LNX.4.64.0709161925000.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"7vk5qq3y76.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-17T02:31:45Z","receivedAt":"2007-09-17T02:31:45Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n>\n>> On Sun, 16 Sep 2007, Junio C Hamano wrote:\n>>>\n>>> I do not think there is nothing that writes file contents to\n>>> stdout/pager other than \"git cat-file\" or \"git show\"; I do not\n>>> think they are what you have in mind when talking about managing\n>>> the files under /etc. So unfortunately I do not understand the\n>>> rest of the discussion you made in your message.\n>>\n>> Ok, I thought that there was common code for these different\n>> uses. could you re-read the rest of the logic based on the change\n>> being done in checkout_entry?\n>>\n>> if you are unwilling to have any changes made to the checkout_entry\n>> code then the only remaing question is what you think of Daniel's\n>> suggestion to have a hook to replace check_updates()?\n>>\n>> if it's not acceptable either then we are down to doing a\n>> post-checkout trigger.\n>\n> Post-checkout trigger is something I can say I can live with\n> without looking at the actual patch, but that does not mean it\n> would be a better approach at all.\n\nwe agree on this much at least :-)\n\n> I would not be able to answer the first question right now; that\n> needs a patch to prove that it can be done with a well contained\n> set of changes that results in a maintainable code.\n\nyou cannot answer the question in the affirmitive, but you could say that \nany changes in that area would be completely unacceptable to you (and for \na while it sounded like you were saying exactly that). in which case any \neffort put into preparing patches would be a waste of time\n\n> I haven't tried to assess the potential extent of damage needed\n> to checkout_entry(), and I have never been interested in this\n> \"keeping track of /etc in place\" topic myself. It is unlikely\n> I'll try to come up with such a patch on my own to support it at\n> such a low level near the core. Somebody who cares about that\n> feature needs to take the initiative of doing that work before\n> we can discuss and decide, although older-times including myself\n> can help spot potential issues.\n>\n> So while I admit I am skeptical, consider me neither willing nor\n> unwilling at this point.\n\nthis is reasonable. thanks for pointing me so clearly at the routine that \nneeds to be modified.\n\nDavid Lang\n"},{"id":"53254","messageId":"7v7imp539u.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161925000.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-17T04:23:09Z","receivedAt":"2007-09-17T04:23:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n>> Post-checkout trigger is something I can say I can live with\n>> without looking at the actual patch, but that does not mean it\n>> would be a better approach at all.\n>\n> we agree on this much at least :-)\n>\n>> I would not be able to answer the first question right now; that\n>> needs a patch to prove that it can be done with a well contained\n>> set of changes that results in a maintainable code.\n>\n> you cannot answer the question in the affirmitive, but you could say\n> that any changes in that area would be completely unacceptable to you\n> (and for a while it sounded like you were saying exactly that). in\n> which case any effort put into preparing patches would be a waste of\n> time\n\nI tend to disagree. It's far from a waste of time. While, as I\nsaid, I am skeptical that such a patch would be small impact, if\nit helps people's needs, somebody will pick it up and carry\nforward, even if that somebody is not me. It can then mature\nout of tree and later could be merged. We simply do not know\nunless somebody tries. And I am quite happy that you seem to be\nmotivated enough to see how it goes.\n\nOn the other hand, the experiment could fail and you may end up\nwith a patch that is too messy to be acceptable, in which case\nyou might feel it a waste of time, but I do not think it is a\nwaste even in such a case. We would learn what works and what\ndoesn't, and we can bury \"keeping track of /etc\" topic to rest.\n\nI also need to rant here a bit.\n\nFortunately we haven't had this problem too many times on this\nlist, but sometimes people say \"Here is my patch. If this is\naccepted I'll add documentation and tests\". I rarely reply to\nsuch patches without sugarcoating my response, but my internal\nreaction is, \"Don't you, as the person who proposes that change,\nbelieve in your patch deeply enough to be willing to perfect it,\nin order to make it suitable for consumption by the general\npublic, whether it is included in my tree or not? A change that\neven you do not believe in yourself has very little chance of\nbenefitting the general public, so thanks but no thanks, I'll\npass.\"\n"},{"id":"53256","messageId":"Pine.LNX.4.64.0709162126380.24221@asgard.lang.hm","threadId":"9838","inReplyTo":"7v7imp539u.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-17T04:35:21Z","receivedAt":"2007-09-17T04:35:21Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n>\n>>> Post-checkout trigger is something I can say I can live with\n>>> without looking at the actual patch, but that does not mean it\n>>> would be a better approach at all.\n>>\n>> we agree on this much at least :-)\n>>\n>>> I would not be able to answer the first question right now; that\n>>> needs a patch to prove that it can be done with a well contained\n>>> set of changes that results in a maintainable code.\n>>\n>> you cannot answer the question in the affirmitive, but you could say\n>> that any changes in that area would be completely unacceptable to you\n>> (and for a while it sounded like you were saying exactly that). in\n>> which case any effort put into preparing patches would be a waste of\n>> time\n>\n> I tend to disagree. It's far from a waste of time. While, as I\n> said, I am skeptical that such a patch would be small impact, if\n> it helps people's needs, somebody will pick it up and carry\n> forward, even if that somebody is not me. It can then mature\n> out of tree and later could be merged. We simply do not know\n> unless somebody tries. And I am quite happy that you seem to be\n> motivated enough to see how it goes.\n>\n> On the other hand, the experiment could fail and you may end up\n> with a patch that is too messy to be acceptable, in which case\n> you might feel it a waste of time, but I do not think it is a\n> waste even in such a case. We would learn what works and what\n> doesn't, and we can bury \"keeping track of /etc\" topic to rest.\n\nthis is perfectly acceptable to me. I was trying to make very sure that \nthis topic fell in this catagory.\n\nthere are other topics that come up repeatedly that do get (and deserve) \nautomatic rejections ('patch to explicitly record renames' for example). \nand while I didn't think that 'managing /etc' was in the same catagory, \nsometimes that catagory is defined as much by the opinions and goals of \nthe core team as it is by techinical considerations.\n\nthere's a huge difference between 'this patch is rejected becouse we think \nthe implementation is bad' and 'this patch is rejected becouse we disagree \nwith the fundamental goal of the patch' effort spent on a patch rejected \nfor the first reason is never a complete waste (if nothing else it can \nserve an an example of how not to do things for future developers ;-) but \neffort spent on a patch that's rejected for the second reason is useually \na waste, and as such I make it a point to discuss the objective and basic \napproach before spending much effort on somthing.\n\n> I also need to rant here a bit.\n>\n> Fortunately we haven't had this problem too many times on this\n> list, but sometimes people say \"Here is my patch. If this is\n> accepted I'll add documentation and tests\". I rarely reply to\n> such patches without sugarcoating my response, but my internal\n> reaction is, \"Don't you, as the person who proposes that change,\n> believe in your patch deeply enough to be willing to perfect it,\n> in order to make it suitable for consumption by the general\n> public, whether it is included in my tree or not? A change that\n> even you do not believe in yourself has very little chance of\n> benefitting the general public, so thanks but no thanks, I'll\n> pass.\"\n>\n\nI hope that my questions did not seem to fall into this catagory.\n\nDavid Lang\n"},{"id":"53262","messageId":"7vtzpt3jwp.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709162126380.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-17T06:06:46Z","receivedAt":"2007-09-17T06:06:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> On Sun, 16 Sep 2007, Junio C Hamano wrote:\n>\n>> I also need to rant here a bit.\n>>\n>> Fortunately we haven't had this problem too many times on this\n>> list, but sometimes people say \"Here is my patch. If this is\n>> accepted I'll add documentation and tests\". I rarely reply to\n>> such patches without sugarcoating my response, but my internal\n>> reaction is, \"Don't you, as the person who proposes that change,\n>> believe in your patch deeply enough to be willing to perfect it,\n>> in order to make it suitable for consumption by the general\n>> public, whether it is included in my tree or not? A change that\n>> even you do not believe in yourself has very little chance of\n>> benefitting the general public, so thanks but no thanks, I'll\n>> pass.\"\n>\n> I hope that my questions did not seem to fall into this catagory.\n\nNot at all.\n"},{"id":"53307","messageId":"38b2ab8a0709170604u8f4474fyd990f61fb250bc93@mail.gmail.com","threadId":"9838","inReplyTo":"86veaby050.fsf@blue.stonehenge.com","subject":"Re: metastore","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-09-17T13:04:18Z","receivedAt":"2007-09-17T13:04:18Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hello,\n\nOn 9/16/07, Randal L. Schwartz wrote:\n> >>>>> \"Grzegorz\" == Grzegorz Kulewski writes:\n>\n> Grzegorz> Not only for tracking /etc or /home but also for example for \"web\n> Grzegorz> applications\" (for example in PHP). In that case file and directory\n> Grzegorz> permissions can be as important as the source code tracked and it is pain to\n> Grzegorz> chmod (and sometimes chown) all files to different values after each\n> Grzegorz> checkout. Not speaking about potential race.\n>\n> Uh, works just fine for me to manage my web site content. The point is\n> that I treat git for what it is... a source code management system.\n> And then I have a Makefile that \"installs\" my source code into the live\n> directory, with the right modes during installation.\n>\n> Why does everyone keep wanting \"work dir == live dir\". Ugh! The work dir is\n> the *source*... it gets *copied* into your live dir *somehow*. And *that* is\n> where the meta information needs to be. In that \"somehow\".\n>\n\nInteresting. Could you show us what this makefile actually looks ?\n\nHow would you create a repo to track /etc ? I'm thinking of importing\nthis directory by using tar, do you think it's correct ?\n\nthanks.\n-- \nFrancis\n"},{"id":"53333","messageId":"20070917133000.GD16773@lapse.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709161507130.24221@asgard.lang.hm","subject":"Re: metastore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-17T13:30:00Z","receivedAt":"2007-09-17T13:30:00Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach david@lang.hm [2007.09.17.0037 +0200]:\n>> While we're at it, you probably don't even want to write the\n>> permission file to the live filesystem. It's just one more thing\n>> that could leak information, and changes to the permissions of\n>> files that you record by committing the live filesystem would\n>> presumably be done by changing the permissions of files in the\n>> filesystem, not by changing the text file.\n>\n> the permissions and ACL's can be queried directly from the\n> filesystem, so I don't see any security problems with writing the\n> permission file to the filesystem.\n>\n> changing the permissions would be done by changing the files\n> themselves (when you are running as root on a filesystem that\n> supports the changes, otherwise it would need to fall back to\n> writing the file and getting the changes there, but that should be\n> able to be a local config option)\n>\n> I don't like the idea of having a file that doesn't appear on the\n> local filesystem at any point, it just makes troubleshooting too\n> hard.\n\nReading over your thoughts, I get this uneasy feeling about such\na permissions file, because it stores redundant information, and\nredundant information has a tendency to get out of sync. If we\ncannot attach attributes to objects in the git database, then\nI understand the need for such a metastore. But I don't think it\nshould be checked out and visible, or maybe we should think of it\nnot in terms of a file anyway, but a metastore. Or how do you want\nto resolve the situation when a user might edit the file, changing\na mode from 644 to 640, while in the filesystem, it was changed by\nother means to 600.\n\n.gitattributes is a different story since it stores git-specificy\nattributes, which are present nowhere else in the checkout.\n\nI still maintain it would be best if git allowed extra data to be\nattached to object nodes. When you start thinking about\ncherry-picking or even simple merges, I think that makes most sense.\nAnd we don't need conflict markers, we could employ an iterative\nmerge process as e.g. git-rebase uses:\n\n \"a conflict has been found in the file mode of ...\n ... 2750 vs. 2755 ...\n please set the file mode as it should be and do git-merge\n --continue. Or git-merge --abort. ...\"\n\n>> (Of course, you could check out the same commits as ordinary source, with\n>> developer-owned 644 files and a 644 \"permissions\" file, and there you'd\n>> have the permissions file appear in the work tree, and you could edit it\n>> and check it in in a totally mundane way.)\n>\n> right, and the same thing if the filesystem doesn't support something in the \n> permission file.\n\nI'd much rather see something like `git-attr chmod 644\nfile-in-index` to make this change, rather than a file, which\nintroduces the potential for syntax errors.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"to me, vi is zen. to use vi is to practice zen. every command is\n a koan. profound to the user, unintelligible to the uninitiated.\n you discover truth everytime you use it.\"\n -- reddy ät lion.austin.ibm.com\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53332","messageId":"20070917133105.GA17536@lapse.madduck.net","threadId":"9838","inReplyTo":"20070916155147.GA30476@efreet.light.src","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-09-17T13:31:05Z","receivedAt":"2007-09-17T13:31:05Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Jan Hudec [2007.09.16.1751 +0200]:\n> > If the filesystem does not support owners, chown() would not\n> > exist. I actually tend to think of things the other way around:\n> > instead of a fallback when chown() does not work (what would\n> > such a fallback be other than not chown()ing?), it would only\n> > try chown() if such functionality existed.\n>·\n> There's a problem. You need to know that the functionality is\n> missing and not try to read attributes back, but instead consider\n> them unchanged. Nothing that can't be taken care of, but it needs\n> to be handled carefuly.\n\nThis is a good consideration. One way of implementing this seems to\nbe to iterate over all file attributes recorded in the object cache\n(or metastore) and try to apply each. For every attribute that was\nproperly applied to the worktree, a note is attached to the object's\ndata in the index. Tools identifying differences between index and\nworktree would then only pay attention to these attributes.\n\n> But if you tar that up again, the owners will be different. But\n> you don't want the change.\n\nAs per my above suggestion, this would solve itself. Untarring as\nnon-root simply means that the chmod/chown/whatever calls would fail\nor not be tried at all. Thus, they would not be recorded in the\nindex and later commits would never consider changes to these\nattributes.\n\nOne could probably simplify the implementation such that failure to\nchmod/chown/whatever a single file would make the attribute be \nignored when worktree and index are compared. Then, it would all \nboil down to a combination of configuration and functionality: the\nattributes the user wants to have tracked (configuration) and those\nwhich can be applied to the worktree when logically and'ed result in\nthe final mask of attributes to consider when identifying changes.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \na gourmet concerned about calories\nis like a punter eyeing the clock.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"53322","messageId":"863axdwbny.fsf@blue.stonehenge.com","threadId":"9838","inReplyTo":"38b2ab8a0709170604u8f4474fyd990f61fb250bc93@mail.gmail.com","subject":"Re: metastore","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-09-17T15:32:01Z","receivedAt":"2007-09-17T15:32:01Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Francis\" == Francis Moreau writes:\n\nFrancis> Interesting. Could you show us what this makefile actually looks ?\n\nIn fact, I wrote a magazine article about it. :)\n\nhttp://www.stonehenge.com/merlyn/LinuxMag/col38.html\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"53334","messageId":"Pine.LNX.4.64.0709171011160.1558@asgard.lang.hm","threadId":"9838","inReplyTo":"20070917133000.GD16773@lapse.madduck.net","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-09-17T17:17:46Z","receivedAt":"2007-09-17T17:17:46Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 17 Sep 2007, martin f krafft wrote:\n\n> also sprach david@lang.hm [2007.09.17.0037 +0200]:\n>>> While we're at it, you probably don't even want to write the\n>>> permission file to the live filesystem. It's just one more thing\n>>> that could leak information, and changes to the permissions of\n>>> files that you record by committing the live filesystem would\n>>> presumably be done by changing the permissions of files in the\n>>> filesystem, not by changing the text file.\n>>\n>> the permissions and ACL's can be queried directly from the\n>> filesystem, so I don't see any security problems with writing the\n>> permission file to the filesystem.\n>>\n>> changing the permissions would be done by changing the files\n>> themselves (when you are running as root on a filesystem that\n>> supports the changes, otherwise it would need to fall back to\n>> writing the file and getting the changes there, but that should be\n>> able to be a local config option)\n>>\n>> I don't like the idea of having a file that doesn't appear on the\n>> local filesystem at any point, it just makes troubleshooting too\n>> hard.\n>\n> Reading over your thoughts, I get this uneasy feeling about such\n> a permissions file, because it stores redundant information, and\n> redundant information has a tendency to get out of sync. If we\n> cannot attach attributes to objects in the git database, then\n> I understand the need for such a metastore. But I don't think it\n> should be checked out and visible, or maybe we should think of it\n> not in terms of a file anyway, but a metastore. Or how do you want\n> to resolve the situation when a user might edit the file, changing\n> a mode from 644 to 640, while in the filesystem, it was changed by\n> other means to 600.\n\neach local repository would need to be configured to either recreate the \npermissions file at checkin time or to use the permission file and ignore \nthe actual permissions on the file.\n\nwhile I agree that it would be ideal to store this data inside git, I'm \nmore interested in getting a functional implementation, and given the \nreluctance of the git core team to allow any changes to support this \nuse-case anything that can be done to minimize the changes needed to \nsupport this use-case is a good thing.\n\n> .gitattributes is a different story since it stores git-specificy\n> attributes, which are present nowhere else in the checkout.\n>\n> I still maintain it would be best if git allowed extra data to be\n> attached to object nodes. When you start thinking about\n> cherry-picking or even simple merges, I think that makes most sense.\n> And we don't need conflict markers, we could employ an iterative\n> merge process as e.g. git-rebase uses:\n>\n> \"a conflict has been found in the file mode of ...\n> ... 2750 vs. 2755 ...\n> please set the file mode as it should be and do git-merge\n> --continue. Or git-merge --abort. ...\"\n\nand there's nothing to prevent the checkin hook from running such a \ncomparison if you want it to.\n\n>>> (Of course, you could check out the same commits as ordinary source, with\n>>> developer-owned 644 files and a 644 \"permissions\" file, and there you'd\n>>> have the permissions file appear in the work tree, and you could edit it\n>>> and check it in in a totally mundane way.)\n>>\n>> right, and the same thing if the filesystem doesn't support something in the\n>> permission file.\n>\n> I'd much rather see something like `git-attr chmod 644\n> file-in-index` to make this change, rather than a file, which\n> introduces the potential for syntax errors.\n\nfirst make this useable, then if it starts getting used widely (which \nwould not at all surprise me, many distros are looking for good options \nfor doing this sort of thing, I wouldn't be surprised to see several of \nthem start useing git if it did the job well) things can be moved from \nexternal scripts and storage to internal capabilities as appropriate.\n\nDavid Lang\n"},{"id":"53335","messageId":"Pine.LNX.4.64.0709171308150.5298@iabervon.org","threadId":"9838","inReplyTo":"7v7imp539u.fsf@gitster.siamese.dyndns.org","subject":"Re: metastore","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-09-17T17:42:06Z","receivedAt":"2007-09-17T17:42:06Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Sep 2007, Junio C Hamano wrote:\n\n> david@lang.hm writes:\n> \n> >> Post-checkout trigger is something I can say I can live with\n> >> without looking at the actual patch, but that does not mean it\n> >> would be a better approach at all.\n> >\n> > we agree on this much at least :-)\n> >\n> >> I would not be able to answer the first question right now; that\n> >> needs a patch to prove that it can be done with a well contained\n> >> set of changes that results in a maintainable code.\n> >\n> > you cannot answer the question in the affirmitive, but you could say\n> > that any changes in that area would be completely unacceptable to you\n> > (and for a while it sounded like you were saying exactly that). in\n> > which case any effort put into preparing patches would be a waste of\n> > time\n> \n> I tend to disagree. It's far from a waste of time. While, as I\n> said, I am skeptical that such a patch would be small impact, if\n> it helps people's needs, somebody will pick it up and carry\n> forward, even if that somebody is not me. It can then mature\n> out of tree and later could be merged. We simply do not know\n> unless somebody tries. And I am quite happy that you seem to be\n> motivated enough to see how it goes.\n\nThere's certainly the possibility that a changeset could consist of some \npatches that make the index/filesystem handling more clear, some patches \nthat make the tree/index handling more clear, and some patches that allow \na hook to replace one of these entirely. Things can be a lot more \nacceptable if the intrusive changes are improvements for the \nmaintainability of the normal case, and the special case code is no longer \nintrusive at all.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"53341","messageId":"7v3axd14nh.fsf@gitster.siamese.dyndns.org","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709171308150.5298@iabervon.org","subject":"Re: metastore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-17T19:19:14Z","receivedAt":"2007-09-17T19:19:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> .... Things can be a lot more \n> acceptable if the intrusive changes are improvements for the \n> maintainability of the normal case, and the special case code is no longer \n> intrusive at all.\n\nVery well said.\n"},{"id":"53342","messageId":"1190058396.6094.39.camel@beauty","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0709171011160.1558@asgard.lang.hm","subject":"Re: metastore","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-09-17T19:46:36Z","receivedAt":"2007-09-17T19:46:36Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"I'd like to point out the following two posts, as I think they are\nrelevant to this thread:\n\n[PATCH] example hook script to save/restore file permissions/ownership\nhttp://marc.info/?l=git&m=118953004817642&w=2\n\n[PATCH] post_merge hook, related documentation, and tests\nhttp://marc.info/?l=git&m=118953004730496&w=2\n\nThe hook script above runs in a pre-commit hook to write out file\nmetadata to a file in the repository. It can then be run from the\npost-merge hook (patch above) to restore permissions. Running it from a\npost-checkout hook may be more appropriate, but post-merge seems to work\nwell for my purposes. The script handles merge conflicts and (in my\ntesting) does the right thing. I'm using it now to track metadata for\nnot just /etc, but an entire linux image.\n\nIt will handle merge conflicts by recognizing that the metadata file had\na conflict, and will direct the user to resolve the conflict and reset\nworking dir perms before allowing a commit.\n\n-JE\n"},{"id":"54497","messageId":"20070919191607.GE13683@hardeman.nu","threadId":"9838","inReplyTo":"20070916060859.GB24124@piper.oerlikon.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"David Härdeman","fromEmail":"david@hardeman.nu","sentAt":"2007-09-19T19:16:07Z","receivedAt":"2007-09-19T19:16:07Z","isPatch":false,"sender":{"key":"david@hardeman.nu","avatar":"https://gravatar.com/avatar/9d166a5d9d3ce5c7aea74a0080677a73785727b9b25f0c3e547d5b359bff27d5?d=mp&s=160"},"body":"On Sun, Sep 16, 2007 at 08:08:59AM +0200, martin f krafft wrote:\n>also sprach Daniel Barkalow [2007.09.15.2156 +0200]:\n>> Configuration options only apply to the local aspects of the repository. \n>> That is, when you clone a repository, you don't get the configuration \n>> options from it, in general. And changing configuration options on a \n>> repository does not have any effect on the content it contains. So \n>> configuration options aren't appropriate.\n>\n>Sure they are. Just like git-commit figures out your email address \n>if user.email is missing from git-config, or core.sharedRepository \n>or core.umask deal with permissions only when you tell them to, \n>you'd have to enable core.track or else git would just do what it\n>does right now.\n>\n>> Git doesn't have any way to represent owners or groups, and they\n>> would need to be represented carefully in order to make sense\n>> across multiple computers. If you're adding support for\n>> metadata-as-content (for more than \"is this a script?\"), you\n>> should be able to cover all of the common cases of extended stuff,\n>> like AFS-style ACLs.\n>\n>Ideally, git should be able to store an open-ended number of\n>properties for each object, yes.\n\nI haven't followed the discussion at all I must admit (I wrote metastore \nas a quick hack to store some extended metadata and it works for my \npurposes as long as I don't do anything fancy). But I agree, if any \nchanges were made to git, I'd advocate adding arbitrary attributes to \nfiles (much like xattrs) in name=value pairs, then any extended metadata \ncould be stored in those attributes and external scripts/tools could use \nthem in some way that makes sense...and also make sure to only update \nthem when it makes sense.\n\n-- \nDavid Härdeman\n"},{"id":"54588","messageId":"20071002195301.GB14171@lapse.madduck.net","threadId":"9838","inReplyTo":"20070919191607.GE13683@hardeman.nu","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T19:53:01Z","receivedAt":"2007-10-02T19:53:01Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach David Härdeman [2007.09.19.2016 +0100]:\n> But I agree, if any changes were made to git, I'd advocate adding\n> arbitrary attributes to files (much like xattrs) in name=value\n> pairs, then any extended metadata could be stored in those\n> attributes and external scripts/tools could use them in some way\n> that makes sense...and also make sure to only update them when it\n> makes sense.\n\nSo where would those metdata be stored in your opinion?\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nseen on an advertising for an elaborate swiss men's watch:\n \"almost as complicated as a woman. except it's on time\"\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54590","messageId":"20071002195816.GA6759@hardeman.nu","threadId":"9838","inReplyTo":"20071002195301.GB14171@lapse.madduck.net","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"David Härdeman","fromEmail":"david@hardeman.nu","sentAt":"2007-10-02T19:58:16Z","receivedAt":"2007-10-02T19:58:16Z","isPatch":false,"sender":{"key":"david@hardeman.nu","avatar":"https://gravatar.com/avatar/9d166a5d9d3ce5c7aea74a0080677a73785727b9b25f0c3e547d5b359bff27d5?d=mp&s=160"},"body":"On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>also sprach David Härdeman [2007.09.19.2016 +0100]:\n>> But I agree, if any changes were made to git, I'd advocate adding\n>> arbitrary attributes to files (much like xattrs) in name=value\n>> pairs, then any extended metadata could be stored in those\n>> attributes and external scripts/tools could use them in some way\n>> that makes sense...and also make sure to only update them when it\n>> makes sense.\n>\n>So where would those metdata be stored in your opinion?\n\nI'm not sufficiently versed in the internals of git to have an informed \nopinion :)\n\n-- \nDavid Härdeman\n"},{"id":"54592","messageId":"85lkalz3iv.fsf@lola.goethe.zz","threadId":"9838","inReplyTo":"20071002195816.GA6759@hardeman.nu","subject":"Re: metastore","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-02T20:04:56Z","receivedAt":"2007-10-02T20:04:56Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Härdeman writes:\n\n> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>>also sprach David Härdeman [2007.09.19.2016 +0100]:\n>>> But I agree, if any changes were made to git, I'd advocate adding\n>>> arbitrary attributes to files (much like xattrs) in name=value\n>>> pairs, then any extended metadata could be stored in those\n>>> attributes and external scripts/tools could use them in some way\n>>> that makes sense...and also make sure to only update them when it\n>>> makes sense.\n>>\n>>So where would those metdata be stored in your opinion?\n>\n> I'm not sufficiently versed in the internals of git to have an\n> informed opinion :)\n\nI think we have something like a length count for file names in index\nand/or tree. We could just put the (sorted) attributes after a NUL\nbyte in the file name and include them in the count. It would also\nmake those artificially longer file names work more or less when\nsorting them for deltification.\n\nHowever, this requires implementing _policies_: it must be possible to\nspecify per repository exactly what will and what won't get tracked,\nor one will get conflicts that are not necessary or appropriate.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"54595","messageId":"Pine.LNX.4.64.0710021314370.24697@asgard.lang.hm","threadId":"9838","inReplyTo":"85lkalz3iv.fsf@lola.goethe.zz","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-02T20:18:24Z","receivedAt":"2007-10-02T20:18:24Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 2 Oct 2007, David Kastrup wrote:\n\n> David Härdeman writes:\n>\n>> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>>> also sprach David Härdeman [2007.09.19.2016 +0100]:\n>>>> But I agree, if any changes were made to git, I'd advocate adding\n>>>> arbitrary attributes to files (much like xattrs) in name=value\n>>>> pairs, then any extended metadata could be stored in those\n>>>> attributes and external scripts/tools could use them in some way\n>>>> that makes sense...and also make sure to only update them when it\n>>>> makes sense.\n>>>\n>>> So where would those metdata be stored in your opinion?\n>>\n>> I'm not sufficiently versed in the internals of git to have an\n>> informed opinion :)\n>\n> I think we have something like a length count for file names in index\n> and/or tree. We could just put the (sorted) attributes after a NUL\n> byte in the file name and include them in the count. It would also\n> make those artificially longer file names work more or less when\n> sorting them for deltification.\n\nthe problem with this is dealing with the attributes outside of git \n(especially when the filesystem can't store the attributes nativly, \nspecificly including things like owners when not running as root)\n\nthis is one of the reasons for talking about useing a seperate file for \nthe attributes (the other being the ability to minimize the impact to \ngit-core of tracking attributes)\n\nDavid Lang\n"},{"id":"54597","messageId":"20071002202333.GB16010@lapse.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0710021314370.24697@asgard.lang.hm","subject":"Re: metastore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T20:23:33Z","receivedAt":"2007-10-02T20:23:33Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach david@lang.hm [2007.10.02.2118 +0100]:\n> the problem with this is dealing with the attributes outside of git \n> (especially when the filesystem can't store the attributes nativly, \n> specificly including things like owners when not running as root)\n\nIn which case you should not be able to manipulate them (as you\ncould not test the result) and any commits could not affect them,\nmeaning they'd just stay unchanged.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nthe unix philosophy basically involves\ngiving you enough rope to hang yourself.\nand then some more, just to be sure.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54598","messageId":"Pine.LNX.4.64.0710021327371.24697@asgard.lang.hm","threadId":"9838","inReplyTo":"20071002202333.GB16010@lapse.madduck.net","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-02T20:29:50Z","receivedAt":"2007-10-02T20:29:50Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 2 Oct 2007, martin f krafft wrote:\n\n> also sprach david@lang.hm [2007.10.02.2118 +0100]:\n>> the problem with this is dealing with the attributes outside of git\n>> (especially when the filesystem can't store the attributes nativly,\n>> specificly including things like owners when not running as root)\n>\n> In which case you should not be able to manipulate them (as you\n> could not test the result) and any commits could not affect them,\n> meaning they'd just stay unchanged.\n\ntwo problems with this\n\n1. you do want to be able to manipulate them\n\n1a. how do you reconcile a conflict during a merge?\n\n2. git is a series of snapshots, what does it mean to 'stay unchanged'?\n\nDavid Lang\n"},{"id":"54599","messageId":"20071002203941.GA18008@lapse.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0710021327371.24697@asgard.lang.hm","subject":"Re: metastore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T20:39:41Z","receivedAt":"2007-10-02T20:39:41Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach david@lang.hm [2007.10.02.2129 +0100]:\n> 1. you do want to be able to manipulate them\n>\n> 1a. how do you reconcile a conflict during a merge?\n\nHow could there be a conflict if you can't make local changes\nbecause you can't represent the attributes locally/natively?\n\n> 2. git is a series of snapshots, what does it mean to 'stay unchanged'?\n\nIn simple terms, let (content,A,B) be an object with content\n\"content\" and extended attributes A,B, and B cannot be represented\nlocally, but a new object is committed with a change to attribute\nA (content2,A2), then the result is (content2,A2,B), as B simply\ncomes from the (corresponding object of the) parent.\n\nOr am I totally misunderstanding?\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nwhen compared to windoze, unix is an operating system.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54602","messageId":"Pine.LNX.4.64.0710021351400.24697@asgard.lang.hm","threadId":"9838","inReplyTo":"20071002203941.GA18008@lapse.madduck.net","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-02T20:54:59Z","receivedAt":"2007-10-02T20:54:59Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 2 Oct 2007, martin f krafft wrote:\n\n> also sprach david@lang.hm [2007.10.02.2129 +0100]:\n>> 1. you do want to be able to manipulate them\n>>\n>> 1a. how do you reconcile a conflict during a merge?\n>\n> How could there be a conflict if you can't make local changes\n> because you can't represent the attributes locally/natively?\n\nyou merge two uptream branches that disagree about the attributes\n\n>> 2. git is a series of snapshots, what does it mean to 'stay unchanged'?\n>\n> In simple terms, let (content,A,B) be an object with content\n> \"content\" and extended attributes A,B, and B cannot be represented\n> locally, but a new object is committed with a change to attribute\n> A (content2,A2), then the result is (content2,A2,B), as B simply\n> comes from the (corresponding object of the) parent.\n>\n> Or am I totally misunderstanding?\n\nit's very possible that I am misunderstanding, but do we really want to \nhave to go back to the parent to duplicate things when creating a new \ncommit?\n\nand aren't you supposed to be able to have more then one parent? if you \ndo, which one would you use?\n\nDavid Lang\n"},{"id":"54606","messageId":"Pine.LNX.4.64.0710021642090.9321@iabervon.org","threadId":"9838","inReplyTo":"20071002195816.GA6759@hardeman.nu","subject":"Re: metastore (was: Track /etc directory using Git)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-02T21:02:48Z","receivedAt":"2007-10-02T21:02:48Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 2 Oct 2007, David Härdeman wrote:\n\n> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n> >also sprach David Härdeman [2007.09.19.2016 +0100]:\n> > > But I agree, if any changes were made to git, I'd advocate adding\n> > > arbitrary attributes to files (much like xattrs) in name=value\n> > > pairs, then any extended metadata could be stored in those\n> > > attributes and external scripts/tools could use them in some way\n> > > that makes sense...and also make sure to only update them when it\n> > > makes sense.\n> >\n> >So where would those metdata be stored in your opinion?\n> \n> I'm not sufficiently versed in the internals of git to have an informed\n> opinion :)\n\nMy theory was that we would provide an API for getting the \"current state\" \nlisting with all of the filenames and matching contents, and leave it up \nto metastore to put things in the filesystem; in the other direction, \nmetastore would build up this state, and we'd store it.\n\nPeople who are using this in practice would set a config option to \ndelegate the \"working tree\" filesystem I/O to metastore, while other \npeople could interact with the state as files describing the state, and \ncould therefore specify operations that are impossible or prohibited on \nthe filesystems that their development is done on.\n\n(This would effectively be like giving people a convenient way of setting \nattributes on entries in a tar file, such that they can edit it to \nrepresent a stste that they can't necessarily create in their own \nfilesystems, and version controlling that; but more convenient, since the \nfile contents are represented as file contents and the attributes are \nplain text in a listing of some sort)\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"54612","messageId":"20071002211518.GA10445@hardeman.nu","threadId":"9838","inReplyTo":"85lkalz3iv.fsf@lola.goethe.zz","subject":"Re: metastore","fromName":"David Härdeman","fromEmail":"david@hardeman.nu","sentAt":"2007-10-02T21:15:18Z","receivedAt":"2007-10-02T21:15:18Z","isPatch":false,"sender":{"key":"david@hardeman.nu","avatar":"https://gravatar.com/avatar/9d166a5d9d3ce5c7aea74a0080677a73785727b9b25f0c3e547d5b359bff27d5?d=mp&s=160"},"body":"On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:\n>David Härdeman writes:\n>\n>> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>>>also sprach David Härdeman [2007.09.19.2016 +0100]:\n>>>> But I agree, if any changes were made to git, I'd advocate adding\n>>>> arbitrary attributes to files (much like xattrs) in name=value\n>>>> pairs, then any extended metadata could be stored in those\n>>>> attributes and external scripts/tools could use them in some way\n>>>> that makes sense...and also make sure to only update them when it\n>>>> makes sense.\n>>>\n>>>So where would those metdata be stored in your opinion?\n>>\n>> I'm not sufficiently versed in the internals of git to have an\n>> informed opinion :)\n>\n>I think we have something like a length count for file names in index\n>and/or tree. We could just put the (sorted) attributes after a NUL\n>byte in the file name and include them in the count. It would also\n>make those artificially longer file names work more or less when\n>sorting them for deltification.\n\nOr perhaps the index format could be extended to include a new field for \nvalue=name pairs instead of overloading the name field.\n\nBut as I said, I have no idea how feasible it would be to change git to \nsupport another arbitrary length field in the index/tree file.\n\n>However, this requires implementing _policies_: it must be possible to\n>specify per repository exactly what will and what won't get tracked,\n>or one will get conflicts that are not necessary or appropriate.\n\nI think the opposite approach would be better. Let git provide \nset/get/delete attribute operations and leave it at that. Then external \nprograms can do what they want with that data and add/remove/modify tags \nas necessary (and also include the smarts to not, e.g. remove the \npermissions on all files if the git repo is checked out to a FAT fs).\n\n-- \nDavid Härdeman\n"},{"id":"54613","messageId":"20071002214237.GA20849@lapse.madduck.net","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0710021351400.24697@asgard.lang.hm","subject":"Re: metastore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T21:42:37Z","receivedAt":"2007-10-02T21:42:37Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach david@lang.hm [2007.10.02.2154 +0100]:\n>> How could there be a conflict if you can't make local changes\n>> because you can't represent the attributes locally/natively?\n>\n> you merge two uptream branches that disagree about the attributes\n\nYou win. :)\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"mein gott, selbst ein huhn kann debian installieren, wenn du genug\n koerner auf die enter-taste legst.\"\n -- thomas koehler in de.alt.sysadmin.recovery\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54614","messageId":"20071002214407.GB20849@lapse.madduck.net","threadId":"9838","inReplyTo":"20071002211518.GA10445@hardeman.nu","subject":"Re: metastore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T21:44:07Z","receivedAt":"2007-10-02T21:44:07Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach David Härdeman [2007.10.02.2215 +0100]:\n> I think the opposite approach would be better. Let git provide\n> set/get/delete attribute operations and leave it at that.\n\nI like that idea.\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"information superhighway\"\n is just an anagram for\n\"i'm on a huge wispy rhino fart\".\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54624","messageId":"Pine.LNX.4.64.0710030018240.4087@reaper.quantumfyre.co.uk","threadId":"9838","inReplyTo":"20071002211518.GA10445@hardeman.nu","subject":"Re: metastore","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-10-02T23:32:18Z","receivedAt":"2007-10-02T23:32:18Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Tue, 2 Oct 2007, David Härdeman wrote:\n\n> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:\n>> David Härdeman writes:\n>> \n>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>> > > also sprach David Härdeman [2007.09.19.2016 +0100]:\n>> > > > But I agree, if any changes were made to git, I'd advocate adding\n>> > > > arbitrary attributes to files (much like xattrs) in name=value\n>> > > > pairs, then any extended metadata could be stored in those\n>> > > > attributes and external scripts/tools could use them in some way\n>> > > > that makes sense...and also make sure to only update them when it\n>> > > > makes sense.\n>> > > \n>> > > So where would those metdata be stored in your opinion?\n>> > \n>> > I'm not sufficiently versed in the internals of git to have an\n>> > informed opinion :)\n>> \n>> I think we have something like a length count for file names in index\n>> and/or tree. We could just put the (sorted) attributes after a NUL\n>> byte in the file name and include them in the count. It would also\n>> make those artificially longer file names work more or less when\n>> sorting them for deltification.\n>\n> Or perhaps the index format could be extended to include a new field for \n> value=name pairs instead of overloading the name field.\n>\n> But as I said, I have no idea how feasible it would be to change git to \n> support another arbitrary length field in the index/tree file.\n>\n>> However, this requires implementing _policies_: it must be possible to\n>> specify per repository exactly what will and what won't get tracked,\n>> or one will get conflicts that are not necessary or appropriate.\n>\n> I think the opposite approach would be better. Let git provide set/get/delete \n> attribute operations and leave it at that. Then external programs can do what \n> they want with that data and add/remove/modify tags as necessary (and also \n> include the smarts to not, e.g. remove the permissions on all files if the \n> git repo is checked out to a FAT fs).\n\nYou need more than that. You need to be able to log, blame etc on the \nattributes. One of the big annoyances of Subversion properties is being \nunable to find out when or why a property value was changed.\n\nI still don't see why the attributes need to be stored in git directly - \nparticularly if you are going to use an external program to actually apply \nany settings - why not store the attributes as normal file (or files) of \nsome sort tracked by git? You could use any number of methods - e.g. use \nan sqlite database stored in the root of your tree, or a ..props \nfile alongside each path that you have properties for. You could even \nwrite a system that uses such a method and was then SCM agnostic, allowing \nyou to keep your attribute tracking system if/when something better than \ngit comes along - or simply share it with less-fortunate souls stuck in an \ninferior system.\n\n-- \nJulian\n\n ---\nA strong conviction that something must be done is the parent of many\nbad measures.\n \t\t-- Daniel Webster"},{"id":"54634","messageId":"Pine.LNX.4.64.0710030151270.28395@racer.site","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0710021743270.25489@asgard.lang.hm","subject":"Re: metastore","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-03T00:52:13Z","receivedAt":"2007-10-03T00:52:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Oct 2007, david@lang.hm wrote:\n\n> in the discussion a few weeks ago I was told that there is a way to look \n> at the contents of a file that hasn't been checked out yet (somehow it \n> exists in a useable form 'in the index') but when I asked for \n> information about how to do this I never got a response.\n\ngit show :\n\n(Note the \":\")\n\nHth,\nDscho\n"},{"id":"54633","messageId":"Pine.LNX.4.64.0710021743270.25489@asgard.lang.hm","threadId":"9838","inReplyTo":"Pine.LNX.4.64.0710030018240.4087@reaper.quantumfyre.co.uk","subject":"Re: metastore","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-03T00:52:25Z","receivedAt":"2007-10-03T00:52:25Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 3 Oct 2007, Julian Phillips wrote:\n\n> Subject: Re: metastore\n> \n> On Tue, 2 Oct 2007, David Härdeman wrote:\n>\n>> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:\n>>> David Härdeman writes:\n>>> \n>>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:\n>>> > > also sprach David Härdeman [2007.09.19.2016 \n>>> +0100]:\n>>> > > > But I agree, if any changes were made to git, I'd advocate adding\n>>> > > > arbitrary attributes to files (much like xattrs) in name=value\n>>> > > > pairs, then any extended metadata could be stored in those\n>>> > > > attributes and external scripts/tools could use them in some way\n>>> > > > that makes sense...and also make sure to only update them when it\n>>> > > > makes sense.\n>>> > > > > So where would those metdata be stored in your opinion?\n>>> > > I'm not sufficiently versed in the internals of git to have an\n>>> > informed opinion :)\n>>> \n>>> I think we have something like a length count for file names in index\n>>> and/or tree. We could just put the (sorted) attributes after a NUL\n>>> byte in the file name and include them in the count. It would also\n>>> make those artificially longer file names work more or less when\n>>> sorting them for deltification.\n>> \n>> Or perhaps the index format could be extended to include a new field for \n>> value=name pairs instead of overloading the name field.\n>> \n>> But as I said, I have no idea how feasible it would be to change git to \n>> support another arbitrary length field in the index/tree file.\n>> \n>>> However, this requires implementing _policies_: it must be possible to\n>>> specify per repository exactly what will and what won't get tracked,\n>>> or one will get conflicts that are not necessary or appropriate.\n>> \n>> I think the opposite approach would be better. Let git provide \n>> set/get/delete attribute operations and leave it at that. Then external \n>> programs can do what they want with that data and add/remove/modify tags as \n>> necessary (and also include the smarts to not, e.g. remove the permissions \n>> on all files if the git repo is checked out to a FAT fs).\n>\n> You need more than that. You need to be able to log, blame etc on the \n> attributes. One of the big annoyances of Subversion properties is being \n> unable to find out when or why a property value was changed.\n>\n> I still don't see why the attributes need to be stored in git directly - \n> particularly if you are going to use an external program to actually apply \n> any settings - why not store the attributes as normal file (or files) of some \n> sort tracked by git? You could use any number of methods - e.g. use an \n> sqlite database stored in the root of your tree, or a ..props file \n> alongside each path that you have properties for. You could even write a \n> system that uses such a method and was then SCM agnostic, allowing you to \n> keep your attribute tracking system if/when something better than git comes \n> along - or simply share it with less-fortunate souls stuck in an inferior \n> system.\n\none other big advantage of keeping things in a normal file, it's easier to \nget the results accepted into git!\n\ndon't forget that the core git maintainers don't really see this as a \nworthwhile effort, so the more intrusive the result is the less likely it \nis to be accepted. It may end up that storing the attributes inside of git \n_is_ the best thing to do, but it's gong to be a whole lot easier to get a \npatch to implement this accepted if it's a migration from an existing, \nheavily used, implementation then if it's from the 'outside' with people \nsaying \"this is a neat thing, we think people would use it if it only had \nthis\"\n\nand even if an internal implementation does end up being the right thing, \nthe exact shape of the API is an item that will require a lot of debate \n(and probably a few false starts) to get right. let's figure out the \nreal-world useage patterns first, and then work from there as appropriate.\n\nshifting back onto implementaion details\n\nin the discussion a few weeks ago I was told that there is a way to look \nat the contents of a file that hasn't been checked out yet (somehow it \nexists in a useable form 'in the index') but when I asked for information \nabout how to do this I never got a response.\n\nthe reason for needing this is that the routines writing the files need to \nbe able to access this information when they are dong so, but that file \nmay not be checked out.\n\nfor that matter, .gitattributes should have a similar problem (if \n.gitattibutes for a directory hasn't been checked out yet how do you know \nif you could do the line ending conversions on a file or not?). how is the \nproblem addressed there? (or is it the case that all the use so far has \nreally not used the per-directory files and everything is in the master \nfile, and that doesn't change enough to find these problems?\n\nDavid Lang"}]}