(doc) move NAME/ details from example.conf to doc/gitolite.conf.mkd
This commit is contained in:
parent
bb7b185c3c
commit
7e81458f04
|
@ -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/".
|
|
||||||
|
|
|
@ -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
|
||||||
|
|
Loading…
Reference in a new issue