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/".