threads / discuss / 28828

Folder level Acces in git

Subject: Folder level Acces in git

## tl;dr

7 messages between Nov 3, 2011 and Nov 4, 2011.

replies: 6people: 5as markdown or json

redhat1981· Nov 3, 2011, 06:10 UTC · lore
Hi,
I am using Gitosis, Adding the gitosis conf file

[group testabc] writable = testabc members = shrii Abhijeet premkumar add cgit = yes gitweb = yes

[group testabc-readonly] readonly = testabc members = Ganesh Shweta add cgit = yes gitweb = yes

Inside the repository, testabc let us say there are folders folder1, folder 2 etc, I want some users to have read/write, read or no access to the folder1 or folder2, Is this possible in Git, I have done it in SVN, Please help!!

redhat1981@gmail.com

-- View this message in context: http://git.661346.n2.nabble.com/Folder-level-Acces-in-git-tp6958047p6958047.html Sent from the git mailing list archive at Nabble.com.

Magnus Bäck· Nov 3, 2011, 07:17 UTC · re: redhat1981 · lore

Re: Folder level Acces in git

On Thursday, November 03, 2011 at 07:10 CET,
     redhat1981 <redhat1981@gmail.com> wrote:
Show 19 quoted lines
> I am using Gitosis, Adding the gitosis conf file
> 
> [group testabc]
> writable = testabc
> members =   shrii Abhijeet premkumar
> add cgit = yes
> gitweb = yes
> 
> 
> [group testabc-readonly]
> readonly = testabc
> members =  Ganesh Shweta
> add cgit = yes
> gitweb = yes
> 
> Inside the repository, testabc let us say there are folders folder1,
> folder 2 etc, I want some users to have read/write, read or no access
> to the folder1 or folder2, Is this possible in Git, I have done it in
> SVN, Please help!!

Given Git's nature, you can't have read access restrictions on a sub-git level (i.e. file/directory level). For basically the same reason, you can never prevent users from making (local) commits that modify certain paths (but you can encourage people to have local hooks to enforce such policies). What you *can* do is install a server-side update hook that rejects attempts to push commits that modify certain paths. If you're willing to trade Gitosis for Gitolite, you get that feature for free.

http://book.git-scm.com/5_git_hooks.html http://progit.org/book/ch4-8.html

-- 
Magnus Bäck                   Opinions are my own and do not necessarily
SW Configuration Manager      represent the ones of my employer, etc.
Sony Ericsson
Jens Lehmann· Nov 3, 2011, 18:13 UTC · re: Magnus Bäck · lore

Re: Folder level Acces in git

Am 03.11.2011 08:17, schrieb Magnus Bäck:
Show 14 quoted lines
> On Thursday, November 03, 2011 at 07:10 CET,
>      redhat1981 <redhat1981@gmail.com> wrote:
>> Inside the repository, testabc let us say there are folders folder1,
>> folder 2 etc, I want some users to have read/write, read or no access
>> to the folder1 or folder2, Is this possible in Git, I have done it in
>> SVN, Please help!!
> 
> Given Git's nature, you can't have read access restrictions on a sub-git
> level (i.e. file/directory level). For basically the same reason, you
> can never prevent users from making (local) commits that modify certain
> paths (but you can encourage people to have local hooks to enforce such
> policies). What you *can* do is install a server-side update hook that
> rejects attempts to push commits that modify certain paths. If you're
> willing to trade Gitosis for Gitolite, you get that feature for free.

Directory read access control can be achieved by putting the directory content into a submodule. You can then control who is allowed to clone from the repo for that submodule separately from the superproject, thereby disallowing a group of people to see (let alone modify) what is in there.

http://progit.org/book/ch6-6.html
Eugene Sajine· Nov 3, 2011, 19:28 UTC · re: redhat1981 · lore

Re: Folder level Acces in git

On Thu, Nov 3, 2011 at 2:10 AM, redhat1981 <redhat1981@gmail.com> wrote:
Show 24 quoted lines
> Hi,
>
> I am using Gitosis, Adding the gitosis conf file
>
> [group testabc]
> writable = testabc
> members =   shrii Abhijeet premkumar
> add cgit = yes
> gitweb = yes
>
>
> [group testabc-readonly]
> readonly = testabc
> members =  Ganesh Shweta
> add cgit = yes
> gitweb = yes
>
> Inside the repository, testabc let us say there are folders folder1, folder
> 2 etc, I want some users to have read/write, read or no access to the
> folder1 or folder2, Is this possible in Git, I have done it in SVN, Please
> help!!
>
> redhat1981@gmail.com
>

Are you sure that the way your have organized the repository is actually correct? If you need to manage the access on folder level why don't you simply split up the project into several repositories/projects which each team is going to work with independently?

This seems to me to be much simpler and cleaner solution then any other alternative.

Thanks, Eugene

Joshua Jensen· Nov 4, 2011, 04:21 UTC · re: Eugene Sajine · lore

Re: Folder level Acces in git

----- Original Message -----
From: Eugene Sajine
Date: 11/3/2011 1:28 PM
Show 9 quoted lines
> Are you sure that the way your have organized the repository is
> actually correct? If you need to manage the access on folder level why
> don't you simply split up the project into several
> repositories/projects which each team is going to work with
> independently?
>
> This seems to me to be much simpler and cleaner solution then any
> other alternative.
>
Submodules are _not_ simple at all.  Our organization of nearly 100 
developers using Git pretty much let out a collective cheer when we 
finally removed the submodules.  Submodules are an absolute pain to 
develop within; there are a number of Git mailing list exchanges about 
that, but I'd be happy to go into great detail if anybody cares.  Even 
submodules that are read-only are a pain as it takes two steps (git pull 
+ git submodule update) to actually get them up to date.
Ick.

In short, if it is an absolute requirement to manage access to a repository on a folder level, get Subversion or Perforce. DVCS is not for you...

Josh
Jens Lehmann· Nov 4, 2011, 08:42 UTC · re: Joshua Jensen · lore

Re: Folder level Acces in git

Am 04.11.2011 05:21, schrieb Joshua Jensen:
Show 13 quoted lines
> ----- Original Message -----
> From: Eugene Sajine
> Date: 11/3/2011 1:28 PM
>> Are you sure that the way your have organized the repository is
>> actually correct? If you need to manage the access on folder level why
>> don't you simply split up the project into several
>> repositories/projects which each team is going to work with
>> independently?
>>
>> This seems to me to be much simpler and cleaner solution then any
>> other alternative.
>>
> Submodules are _not_ simple at all.  Our organization of nearly 100 developers using Git pretty much let out a collective cheer when we finally removed the submodules.  Submodules are an absolute pain to develop within; there are a number of Git mailing list exchanges about that, but I'd be happy to go into great detail if anybody cares.
I do care and would appreciate if you could share your problems.
> Even submodules that are read-only are a pain as it takes two steps (git pull + git submodule update) to actually get them up to date.

Full Ack. I'm working on teaching git to update update the whole work tree - including the submodules - after each checkout, merge, pull, bisect, etc. (which also includes proper support for deletion and re-creation of submodules).

What else made using submodules hard for you?
Eugene Sajine· Nov 4, 2011, 15:59 UTC · re: Joshua Jensen · lore

Re: Folder level Acces in git

On Fri, Nov 4, 2011 at 12:21 AM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:

Show 28 quoted lines
> ----- Original Message -----
> From: Eugene Sajine
> Date: 11/3/2011 1:28 PM
>>
>> Are you sure that the way your have organized the repository is
>> actually correct? If you need to manage the access on folder level why
>> don't you simply split up the project into several
>> repositories/projects which each team is going to work with
>> independently?
>>
>> This seems to me to be much simpler and cleaner solution then any
>> other alternative.
>>
> Submodules are _not_ simple at all.  Our organization of nearly 100
> developers using Git pretty much let out a collective cheer when we finally
> removed the submodules.  Submodules are an absolute pain to develop within;
> there are a number of Git mailing list exchanges about that, but I'd be
> happy to go into great detail if anybody cares.  Even submodules that are
> read-only are a pain as it takes two steps (git pull + git submodule update)
> to actually get them up to date.
>
> Ick.
>
> In short, if it is an absolute requirement to manage access to a repository
> on a folder level, get Subversion or Perforce.  DVCS is not for you...
>
> Josh
>

That is exactly what i wanted to say. I suggest OP not to go into submodules, but just have separate repositories. I think if they need this kind of granularity in permissions it means that their repository is too big and incorrectly organized. I think they are trying to migrate to better VCS (as git is superior by definition;) ), but they still think in central VCS terms and that's what causing this folder level management requirement to appear. We at $work have hundreds of repositories and never had any need of submodules or folder level permissions. (One repo = one project = one artifact) + Ivy as dependency manager works just fine and if we will need to fine tune the permissions it will be always pretty easy to do.

Thanks, Eugene

← back to recent threads