Folder level Acces in git

Folder level Acces in git

[redhat1981]

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.

Re: Folder level Acces in git

[Magnus Bäck]

On Thursday, November 03, 2011 at 07:10 CET,
     redhat1981 <redhat1981@gmail.com> wrote:

> 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

Re: Folder level Acces in git

[Jens Lehmann]

Am 03.11.2011 08:17, schrieb Magnus Bäck:
> 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

Re: Folder level Acces in git

[Eugene Sajine]

On Thu, Nov 3, 2011 at 2:10 AM, redhat1981 <redhat1981@gmail.com> wrote:
> 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

Re: Folder level Acces in git

[Joshua Jensen]

----- 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

Re: Folder level Acces in git

[Jens Lehmann]

Am 04.11.2011 05:21, schrieb Joshua Jensen:
> ----- 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?

Re: Folder level Acces in git

[Eugene Sajine]

On Fri, Nov 4, 2011 at 12:21 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> ----- 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