(doc) move NAME/ details from example.conf to doc/gitolite.conf.mkd

This commit is contained in:
Sitaram Chamarty 2012-01-23 05:53:29 +05:30
parent bb7b185c3c
commit 7e81458f04
2 changed files with 35 additions and 45 deletions

View file

@ -1,47 +1,2 @@
# see doc/gitolite.conf.mkd for help on the syntax and semantics of this file # 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 # 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/".

View file

@ -290,6 +290,41 @@ allowing the secret branches into it).
The previous section is sufficient for most common needs, but gitolite can go The previous section is sufficient for most common needs, but gitolite can go
a lot further than that. a lot further than that.
### restricting pushes by dir/file name using NAME/
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/".
### #deny "deny" rules ### #deny "deny" rules
#### warnings and required reading #### warnings and required reading