advanced access control

"deny" rules

Warning: When using deny rules, the order of your rules matters, where earlier it did not.

PROCESSING LOGIC:

The first matching refex that has the permission you're looking for (W or +) or a minus (-), results in success or failure, respectively. A fallthrough also results in failure.

    RW refs/tags/v[0-9]     = ashok
    -  refs/tags/v[0-9]     = @staff
    RW refs/tags            = @staff

This allows only Ashok to write "version tags" (see rule for Ashok the QA guy somewhere above). The others can write any tags they want, except version tags. To understand this, try and match each rule in sequence with the name of the tag being pushed, and the user doing it, applying the logic described earlier.

for non-version tags, only the 3rd rule matches, so anyone on staff can push them
for version tags by ashok, the first rule matches so he can push them
for version tags by staffers other than ashok, the second rule matches before the third one, and it has a - as the permission, so the push fails

rule accumulation

Rules accumulate. Even when separated by rules for other repos. They accumulate intuitively. For example:

repo foo
    RW+             =   alice

repo bar
    RW+             =   dilbert

repo @all
    RW  dev/USER/   =   @staff

repo foo
    RW+ tmp/        =   @staff

has the effective ruleset, for repo foo, of

repo foo
    RW+             =   alice
    RW  dev/USER/   =   @staff
    RW+ tmp/        =   @staff

Just remember that if you use deny rules anywhere then the order of the rules matters!

gitweb and daemon

Gitolite does NOT do anything for gitweb and daemon access except

for daemon, create the file git-daemon-export-ok in the repository
for gitweb, add the repo (plus owner name, if given) to the list of projects to be served by gitweb (see the config file variable $PROJECTS_LIST, which should have the same value you specified for $projects_list when setting up gitweb)
put the description, if given, in $repo/description