3

For example: I have a repository - repo1 with such fs hierarchy

repo1:
 js
 html
 php/core
 php/menu

And I want to give to repo1:php/menu, RW permission - to a freelancer, but for all repo1 - this freelancer must have only Read-Only permission.

Can I do this with gitolite or gitosis or may be something else?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
silent-ion
  • 31
  • 1
  • 3

3 Answers3

6

The repo access rights on a DVCS is always linked to the all repo, not part of if, mainly because you clone all of it (shallow clone is hard).

That means gitolite (I won't even mention gitosis which is obsolete) can establish restrictions on:

  • accessing a all repo
  • writing only certain branches (but you cannot limit read access to certain branch)

But it cannot prevent a user to access parts of a repo.

However, since gitolite v3 or 'g3' (April 17th, 2012), you can, with VREF rules, prevent writing (pushing to) certain directories (in addition of certain branches).

Original answer (gitolite V2 or 'g2', November 2011)

See gitolite.conf -- by example and side note: "R" permissions for refs

repo    gitolite-admin
        RW+                 =   sitaram
        # this is equivalent to:
        RW+     refs/.*     =   sitaram

Sitaram is the only admin. He can push, create, delete, or rewind any branch or tag in the gitolite-admin repo.

        R master    =   wally       # MEANINGLESS!  WILL NOT DO WHAT YOU THINK IT DOES!

This won't work.
You can only restrict "read" access at the repo level, not at the branch level.
This is a git issue, not a gitolite issue. Go bother them, or switch to gerrit.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Given gerrit is also based on git this shows it's actually possible to work around the issue. – Jan Hudec Nov 08 '11 at 08:40
  • @JanHudec - quoting from Gitolite... "Meanwhile, people who desperately need this are directed to gerrit, which can do this because they have their own git stack and dont use the one written by Linus and currently maintained by Junio. With the native git stack, the best solution is to create a second repo and use that for the more "secret" branches. " – Ash Nov 08 '11 at 09:05
  • You are right about the read access. It can be given at repo level only but write access can be controlled at branch and tag levels – Ash Nov 08 '11 at 09:09
  • @Ashley: Hm, that quote is total nonsense. There is nothing the Java reimplementation could possibly allow that the C one does not. – Jan Hudec Nov 08 '11 at 10:43
  • It is nobody's issue. It's a feature that could possibly be added to gitolite. It just does not make that much sense, so nobody did. – Jan Hudec Nov 08 '11 at 10:48
0

What you want to do seems possible with gitolite. Look at this: http://sitaramc.github.com/gitolite/bac.html

Read access will be at repo level only, however but thats what you want anyways..

Ash
  • 128
  • 2
  • 11
0

First issue is what does it mean "read-only" and "read-write" in context of git. A "write" in git consists of two separate operations. The "commit", which creates a revision spanning whole tree (git does not have any per-file history at all) and a "push" that copies that revision into your central repository.

There is no way to limit the "commit" for anybody but yourself, since user must install any hooks into their working repository manually. So the user in question will be able to create a commit modifying anything at all. They will also be able to share that commit with other members of your team by sending patch, bundle or allowing them to pull from the work repository directly.

What you can limit is the "push" to the central repository. You can create an update or pre-receive hook (they only differ in calling convention) that will check content of the revisions and reject them if they touch something you don't want. The update hook receives 3 arguments, branch name, old commit and new commit, so you would just git diff --name-status the old and new commit and if given user (you'll have to look up how to get that from gitolite) is doing the push and the changes affect other than the subdirectory you allow, reject the push.

The user will still be able to author a revision that affects other parts of the tree and get it into the trunk by having somebody else push it. It might be useful, but your colleagues need to be aware that they should review changes they pull from the consultant directly.

Note, that checking commit authors or committers is not secure, because the author can be set freely.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172