gitolite/conf/example.conf

# see doc/gitolite.conf.mkd for help on the syntax and semantics of this file
# online at http://sitaramc.github.com/gitolite/doc/gitolite.conf.html



# this file now has docs for just 2 features



# (1) NAME/ restrctions: documentation for this feature currently does not fit
# anywhere else, so it's still here

# FILE/DIR NAME BASED RESTRICTIONS
# --------------------------------

# Here's a hopefully self-explanatory example.  Assume the project has the
# following contents at the top level: a README, a "doc/" directory, and an
# "src/" directory.

repo foo
        RW+                             =   lead_dev                # rule 1
        RW                              =   dev1 dev2 dev3 dev4     # rule 2

        RW  NAME/                       =   lead_dev                # rule 3
        RW  NAME/doc/                   =   dev1 dev2               # rule 4
        RW  NAME/src/                   =   dev1 dev2 dev3 dev4     # rule 5

# Notes

# - the "NAME/" is part of the syntax; think of it as a keyword if you like.
#   The rest of it is treated as a refex to match against each file being
#   touched (see "SPECIFYING AND USING A REFEX" above for details)

# - file/dir NAME-based restrictions are *in addition* to normal (branch-name
#   based) restrictions; they are not a *replacement* for them.  This is why
#   rule #2 (or something like it, maybe with a more specific branch-name) is
#   needed; without it, dev1/2/3/4 cannot push any branches.

# - if a repo has *any* NAME/ rules, then NAME-based restrictions are checked
#   for *all* users.  This is why rule 3 is needed, even though we don't
#   actually have any NAME-based restrictions on lead_dev.  Notice the pattern
#   on rule 3.

# - *each* file touched by the commits being pushed is checked against those
#   rules.  So, lead_dev can push changes to any files, dev1/2 can push
#   changes to files in "doc/" and "src/" (but not the top level README), and
#   dev3/4 can only push changes to files in "src/".



# (2) rsync helper: this is an oddball feature that only the person who asked
# me for is apparently using, created long ago, before I learned the value of
# saying "no" :-)  These items just don't seem to fit in any of the existing
# documents.

# EXTERNAL COMMAND HELPERS -- RSYNC
# ---------------------------------

# If $RSYNC_BASE is non-empty, the following config entries come into play
# (otherwise they are ignored):

# a "fake" git repository to collect rsync rules.  Gitolite does not
# auto-create any repo whose name starts with EXTCMD/
repo    EXTCMD/rsync
# grant permissions to files/dirs within the $RSYNC_BASE tree.  A leading
# NAME/ is required as a prefix; the actual path starts after that.  Matching
# follows the same rules as given in "FILE/DIR NAME BASED RESTRICTIONS" above
        RW  NAME/                       =   sitaram
        RW  NAME/foo/                   =   user1
        R   NAME/bar/                   =   user2
# just to remind you that these are perl regexes, not shell globs
        RW  NAME/baz/.*/*.c             =   user3