(minor doc fixes)

doc/gitolite.conf.mkd

@@ -412,6 +412,15 @@ Elsewhere in the file, you would specify access for individual repos (like RW,
 RW+, etc).  Gitolite combines all of these access rules, maintaining the
 textual order in which they occur, when authorising a push.
 
+And although this example used groups, you can use reponames as well, or mix
+and match them.  You can even distribute rulesets across multiple "include"
+files if you wish.
+
+Just remember that if you use [deny rules][dr] anywhere then the *order of the
+rules matters*!
+
+[dr]: http://sitaramc.github.com/gitolite/doc/gitolite.conf.html#_deny_rules
+
 This feature also helps people who generate their gitolite.conf itself from
 some *other* database -- it allows them much more flexibility in how they
 generate rules.

doc/overkill.mkd

@@ -38,6 +38,16 @@ the "--shared" argument, do this on each of them:
 
 I think that should do it.
 
+Once you've setup the Unix level permissions, you may consider setting the
+shell of some of the less experienced users to "git-shell" (using its full
+path) if they don't really need a shell on the server.  This will let them
+access git remotely but not do anything else.
+
+Combining this with settings like `receive.denyDeletes` and
+`receive.denyNonFastForwards`, or at least `core.logAllRefUpdates`, can go a
+long way toward preventing accidents or at least making it feasible to recover
+from them.
+
 ----
 
 You can do more complex things using Unix acls.  If you do, and feel like