master TOC | chapter TOC | support

handing out rights to wildcard-matched repos

In the examples above, we saw two special "user" names: READERS and WRITERS. The permissions they have are controlled by the config file, but who is part of this list is controlled by the person who created the repository.

The use case is that, although our toy example has only 3 students, in reality there will be a few dozen, but each assignment will be worked on only by a handful from among those. This allows the creator to take ad hoc sets of users from among the actual users in the system, and give them one of two roles (in this example, READERS and WRITERS respectively). In theory you could do the same thing by creating lots of little "assignment-NN" groups in the config file but that may be a little too cumbersome for non-secret environments.

Create a small text file that contains the permissions you desire:

$ cat > myperms
READERS u5
WRITERS u6
(hit ctrl-d here)

...and use the new setperms command to set permissions for your repo:

$ ssh git@server setperms assignments/u4/a12 < myperms
New perms are:
READERS u5
WRITERS u6

'setperms' will helpfully print what the new permissions are but you can also use getperms to check:

$ ssh git@server getperms assignments/u4/a12
READERS u5
WRITERS u6

The following points are important:

(admin) adding other roles than READERS and WRITERS

Let's say your needs are more complex and you need more roles. For example, you might like to have a setup where only a tester can update tags, and only a manager can delete branches:

repo foo/..*
  C                 =   u1
  RW    refs/tags/  =   TESTERS
  -     refs/tags/  =   @all
  RW+               =   WRITERS
  RW                =   INTERNS
  R                 =   READERS
  RW+D              =   MANAGERS

As you can see, someone pre-creates the repo and assigns rights to various people, say by sending something like this to setperms:

READERS wally
WRITERS dilbert alice
MANAGERS phb
INTERNS ashok
TESTERS ashok

You can enable this by setting the GL_WILDREPOS_PERM_CATS variable in the rc file. The rc file documentation (doc/gitolite.rc.mkd) explains how.

IMPORTANT WARNING ABOUT THIS FEATURE

Please make sure that none of the role names conflict with any of the usernames in the system. For example, if you have a user called "foo", make sure you do not include "foo" as a valid role in $GL_WILDREPOS_PERM_CATS.

You can keep things sane by using UPPERCASE names for roles, while keeping all your usernames lowercase; then you don't have to worry about this problem.