deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

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

Browse source
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
Show stats Download patch file Download diff file Expand all files Collapse all files

45
conf/example.conf
View file

@ -1,47 +1,2 @@
# 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/".

35
doc/gitolite.conf.mkd
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
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
#### warnings and required reading