master TOC | chapter TOC | support
IMPORTANT NOTE:
This feature may be somewhat "brittle" in terms of security. Creating repositories based on wild cards, giving "ownership" to the specific user who created it, allowing him/her to hand out permissions to other users to collaborate, all these are possible. And any of these could have a bug in it. I haven't found any yet, but that doesn't mean there aren't any.
This document is mostly "by example".
The wildrepos feature allows you to specify access control rules using regular
expression patterns, so you can have many actual repos being served by a
single set of rules in the config file. The regex pattern can also include
the word CREATOR in it, allowing you to parametrise the name of the user
creating the repo. The examples below will make this clearer.
This feature requires that you set $GL_WILDREPOS to "1" in ~/.gitolite.rc
on the server. Please search for that variable in doc/gitolite.rc.mkd
for more information on this.
As the introduction said, you can include the word CREATOR in the regex
pattern, though it is not mandatory. We'll look at examples of both types of
usage.
Which of these alternatives you choose depends on your needs, and the social aspects of your environment. Including the creator name in the pattern keeps users rigidly separated from each others repos, and is good for a largely autonomous collection of users with a high probability of repo name clashes.
Omitting the creator name from the pattern puts the repos in a common namespace, and is suitable for environments where it is not very important to keep track of who actually created the repo (except for granting access), but needs more communication / co-operation among the users to avoid repo name clashes.
Here's an example snippet:
@prof = u1
@TAs = u2 u3
@students = u4 u5 u6
repo assignments/CREATOR/a[0-9][0-9]
C = @students
RW+ = CREATOR
RW = WRITERS @TAs
R = READERS @prof
Note the "C" permission. This is a standalone "C", which gives the named users the right to create a repo. This is not to be confused with the "RWC" or its variants described elsewhere, which are about branches, not repos.
For now, ignore the special usernames READERS and WRITERS, and just create a new repo, as user "u4" (a student):
$ git clone git@server:assignments/u4/a12
Initialized empty Git repository in /home/sitaram/t/a12/.git/
Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a12.git/
warning: You appear to have cloned an empty repository.
Notice the two empty repo inits, and the order in which they occur ;-)
Here's how the same example would look if you did not want the CREATOR's name to be part of the actual repo name.
repo assignments/a[0-9][0-9]
C = @students
RW+ = CREATOR
RW = WRITERS @TAs
R = READERS @prof
We haven't changed anything except the repo name pattern. This means that the
first student that creates, say, assignments/a12 becomes the owner.
Mistakes (such as claiming a12 instead of a13) need to be rectified by an
admin logging on to the back end, though it's not too difficult.
You could also repace the C line like this:
C = @TAs
and have a TA create the repos in advance.
In either case, they could then use the setperms feature to specify which
users are "READERS" and which are "WRITERS". See later for details.
Similar to the getperms/setperms commands, there are the getdesc/setdesc commands, thanks to Teemu.
In order to see what repositories were created from a wildcard, use the "expand" command.
See repo deletion for more on this. Note that this requires you to install/setup "adc"s (admin defined commands). See admin-defined-commands for how to do that.
Enjoy, and please use with care. This is pretty powerful stuff. As they say: if you break it, you get to keep both pieces :)