85da5572b2
- support for ADCs with unchecked arguments - rsync, htpasswd, and svnserve gone from core; turned into ADCs Backward compat breakage and fix: Please see documentation for details, but if you're using gitolite to control rsync you will now need to setup ADCs (admin defined commands), and install at least the new "rsync" ADC. ---- Thanks to Joey Hess (see commit prior to this) for forcing me to stop being lazy and get this out of my long term todo list.
48 lines
2 KiB
Plaintext
48 lines
2 KiB
Plaintext
# 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/".
|