{"thread":{"id":"39793","subject":"Whether Git supports directory level access or not?","startedAt":"2015-07-07T06:40:25Z","lastAt":"2015-07-07T23:03:47Z","messageCount":5,"participants":["saurabh@stockal.com","Torsten Bögershausen","Jacob Keller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"265646","messageId":"705bdbdc6a8195d59203bcb1f3027714@stockal.com","threadId":"39793","inReplyTo":null,"subject":"Whether Git supports directory level access or not?","fromName":"","fromEmail":"saurabh@stockal.com","sentAt":"2015-07-07T06:40:25Z","receivedAt":"2015-07-07T06:40:25Z","isPatch":false,"sender":{"key":"saurabh@stockal.com","avatar":null},"body":"Hi,\n\nPlease let me know whether Git supports directory level access or not.\n\nFor example :- Consider the structure with one repository consisting of \nsub directories for each product.\nmain_repo:\n dir1 dir\n dir2 dir\n shared-dir dir\n private dir\nOne group(user) of developers has access to dir1 and shared-dir while \nthe other group(user) has access to dir2 and shared-resources.\nJust for context, both dir1 and dir2 require shared-dir to be checked \nout for building the products.\n\nAnd private dir is only accessible by admin(repo owner).\n\nRegards\nSaurabh gaur\n"},{"id":"265651","messageId":"559B7CD2.1040507@web.de","threadId":"39793","inReplyTo":"705bdbdc6a8195d59203bcb1f3027714@stockal.com","subject":"Re: Whether Git supports directory level access or not?","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-07-07T07:16:34Z","receivedAt":"2015-07-07T07:16:34Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 07.07.15 08:40, saurabh@stockal.com wrote:\n> Hi,\n> \n> Please let me know whether Git supports directory level access or not.\n> \n> For example :- Consider the structure with one repository consisting of sub directories for each product.\n> main_repo:\n> dir1 dir\n> dir2 dir\n> shared-dir dir\n> private dir\n> One group(user) of developers has access to dir1 and shared-dir while the other group(user) has access to dir2 and shared-resources.\n> Just for context, both dir1 and dir2 require shared-dir to be checked out for building the products.\n> \n> And private dir is only accessible by admin(repo owner).\n> \n> Regards\n> Saurabh gaur\n\nGit is a distributed VCS.\nIf you do a clone, all information is available on your local machine.\n\nSolution:\nUse a different repo for private stuff, in your example you need 4 repos,\nwhich has the advantage that each product has it's own repo.\n\nHTH\n"},{"id":"265652","messageId":"CA+P7+xpqk2m2Mxv_12Mg+03GzqVa5kzVk29HAOMiW9EGpmrWww@mail.gmail.com","threadId":"39793","inReplyTo":"705bdbdc6a8195d59203bcb1f3027714@stockal.com","subject":"Re: Whether Git supports directory level access or not?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-07T07:20:27Z","receivedAt":"2015-07-07T07:20:27Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi\n\nOn Mon, Jul 6, 2015 at 11:40 PM, wrote:\n> Hi,\n>\n> Please let me know whether Git supports directory level access or not.\n>\n> For example :- Consider the structure with one repository consisting of sub\n> directories for each product.\n> main_repo:\n> dir1 dir\n> dir2 dir\n> shared-dir dir\n> private dir\n> One group(user) of developers has access to dir1 and shared-dir while the\n> other group(user) has access to dir2 and shared-resources.\n> Just for context, both dir1 and dir2 require shared-dir to be checked out\n> for building the products.\n>\n> And private dir is only accessible by admin(repo owner).\n>\n> Regards\n> Saurabh gaur\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\nI do not believe this is possible with git. How would this even make\nsense? You can do something with sub-repositories on the server end,\nwhere each directory is its own repository with different access\nrights (and servers like gerrit or other git server setups have\nvarious controls which enable more complex access control beyond just\nUnix paths)\n\nHowever, in-repo per-directory permissions make no sense, as there\nwould be no way to generate commits.\n\nRegards,\nJake\n"},{"id":"265755","messageId":"xmqq7fqb529c.fsf@gitster.dls.corp.google.com","threadId":"39793","inReplyTo":"CA+P7+xpqk2m2Mxv_12Mg+03GzqVa5kzVk29HAOMiW9EGpmrWww@mail.gmail.com","subject":"Re: Whether Git supports directory level access or not?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-07T17:03:11Z","receivedAt":"2015-07-07T17:03:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n> However, in-repo per-directory permissions make no sense, as there\n> would be no way to generate commits.\n\nThat may be the case for the current generation of Git, but I do not\nthink you have to be so pessimistic.\n\nSuppose that an imaginary future version of Git allowed you to\n\"hide\" one directory from you. That is:\n\n * A commit object records \"tree\". \"git cat-file -t HEAD^{tree}\"\n or \"git ls-tree HEAD\" lets you inspect its contents;\n\n * The \"hidden\" directory shows up as one of the subtrees of that\n output. It may say\n\n 040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4 hidden\n\n * However, your repository lack b4006c40... object. So if you did\n \"git ls-tree HEAD:hidden\", you would get \"no such tree object\".\n\n * This imaginary future version of Git has a new implementation of\n the index (both on-disk and in-core) that lets you keep just the\n \"tree\" entry for an unmodified directory, without having to store\n any of the files and subdirectories in it.\n\n * All the other machinery of this imaginary future version of Git\n are aware of the fact that \"hidden\" thing is not visible, or even\n available, to your clone of the project repository. That means\n \"fsck\" does not complain about missing object b4006c40..., \"push\"\n knows it should not consider it an error that you cannot enumerate\n and send objects that are reachable from b4006c40..., etc.\n\nWith such a Git, you can modify anything outside the parts of the\nproject tree that are hidden from you, and make a commit. The tree\nrecorded in a new commit object would record the same\n\n 040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4 hidden\n\nfor the \"hidden\" directory, and you can even push it back to update\nthe parts for other people to see your work outside the \"hidden\"\narea.\n\n\"All the other machinery\" that would need to accomodate such a\nhidden directory would span the entire plumbing layer and\ntransports. The wire protocol would need to be updated, especially\nthe part that determines what needs to be sent and received, which\nis currently purely on commit ancestry, needs to become aware of the\npaths.\n\nI am *NOT* saying that this is easy. I'd imagine if we gather all\nthe competent Gits in a room and have them work on it and doing\nnothing else for six months, we would have some system that works.\nIt would be a lot of work.\n\nI think it may be worth doing in the longer term, and it will likely\nto have other benefits as side effects.\n\n - For example, did you notice that my description above does not\n mention \"permission\" even once? Yes, that's right. This does\n not have to be limited to permissions. The user may have decided\n that the \"hidden\" part of that directory structure is not\n interesting and said \"git clone --exclude=hidden\" when she made\n her clone to set it up.\n\n - Also notice that the \"new implementation of the index\" that\n lazily expands subtrees does not say anythying about a directory\n that is \"hidden\"---it just said \"an unmodified directory\" and\n that was deliberate. Even when you are not doing a \"narrow\n clone\", keeping an untouched tree without expanding its subtrees\n and blobs flatted into the index may make it faster when you are\n working on a series of many small commits each of which touches\n only a handful of files.\n\nI might agree with you that \"in-repo per-directory permissions make\nno sense\", but the reason to say so would not be because \"there\nwould be no way to generate commits\".\n"},{"id":"265782","messageId":"CA+P7+xrRd9tv=cMmz+RtOtrjMwUBVpbdR5VfNG-CVzoHenCF9A@mail.gmail.com","threadId":"39793","inReplyTo":"xmqq7fqb529c.fsf@gitster.dls.corp.google.com","subject":"Re: Whether Git supports directory level access or not?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-07T23:03:47Z","receivedAt":"2015-07-07T23:03:47Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Jul 7, 2015 at 10:03 AM, Junio C Hamano wrote:\n> Jacob Keller writes:\n>\n>> However, in-repo per-directory permissions make no sense, as there\n>> would be no way to generate commits.\n>\n> That may be the case for the current generation of Git, but I do not\n> think you have to be so pessimistic.\n>\n> Suppose that an imaginary future version of Git allowed you to\n> \"hide\" one directory from you. That is:\n>\n> * A commit object records \"tree\". \"git cat-file -t HEAD^{tree}\"\n> or \"git ls-tree HEAD\" lets you inspect its contents;\n>\n> * The \"hidden\" directory shows up as one of the subtrees of that\n> output. It may say\n>\n> 040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4 hidden\n>\n> * However, your repository lack b4006c40... object. So if you did\n> \"git ls-tree HEAD:hidden\", you would get \"no such tree object\".\n>\n> * This imaginary future version of Git has a new implementation of\n> the index (both on-disk and in-core) that lets you keep just the\n> \"tree\" entry for an unmodified directory, without having to store\n> any of the files and subdirectories in it.\n>\n> * All the other machinery of this imaginary future version of Git\n> are aware of the fact that \"hidden\" thing is not visible, or even\n> available, to your clone of the project repository. That means\n> \"fsck\" does not complain about missing object b4006c40..., \"push\"\n> knows it should not consider it an error that you cannot enumerate\n> and send objects that are reachable from b4006c40..., etc.\n>\n> With such a Git, you can modify anything outside the parts of the\n> project tree that are hidden from you, and make a commit. The tree\n> recorded in a new commit object would record the same\n>\n> 040000 tree b4006c408979a0c6261dbfaeaa36639457469ad4 hidden\n>\n> for the \"hidden\" directory, and you can even push it back to update\n> the parts for other people to see your work outside the \"hidden\"\n> area.\n>\n> \"All the other machinery\" that would need to accomodate such a\n> hidden directory would span the entire plumbing layer and\n> transports. The wire protocol would need to be updated, especially\n> the part that determines what needs to be sent and received, which\n> is currently purely on commit ancestry, needs to become aware of the\n> paths.\n>\n> I am *NOT* saying that this is easy. I'd imagine if we gather all\n> the competent Gits in a room and have them work on it and doing\n> nothing else for six months, we would have some system that works.\n> It would be a lot of work.\n>\n> I think it may be worth doing in the longer term, and it will likely\n> to have other benefits as side effects.\n>\n> - For example, did you notice that my description above does not\n> mention \"permission\" even once? Yes, that's right. This does\n> not have to be limited to permissions. The user may have decided\n> that the \"hidden\" part of that directory structure is not\n> interesting and said \"git clone --exclude=hidden\" when she made\n> her clone to set it up.\n>\n> - Also notice that the \"new implementation of the index\" that\n> lazily expands subtrees does not say anythying about a directory\n> that is \"hidden\"---it just said \"an unmodified directory\" and\n> that was deliberate. Even when you are not doing a \"narrow\n> clone\", keeping an untouched tree without expanding its subtrees\n> and blobs flatted into the index may make it faster when you are\n> working on a series of many small commits each of which touches\n> only a handful of files.\n>\n> I might agree with you that \"in-repo per-directory permissions make\n> no sense\", but the reason to say so would not be because \"there\n> would be no way to generate commits\".\n\nActually as you laid out here, it does make sense I had just assumed\nyou would need the tree object to actually be able to generate the\ncommits. It does sound like a lot of work though.\n\nRegards,\nJake\n"}]}