add 2 new sections to "special features"...

- using pubkeys obtained from elsewhere
  - updating hooks via the admin repo

doc/master-toc.mkd

@@ -100,6 +100,8 @@
       * ([link][NAME]: the NAME VREF)
       * the [subconf][] command
   * ([link][partial-copy]: faking selective READ control)
+  * using pubkeys obtained [from elsewhere][keysonly]
+  * [updating hooks][pushhook] via the admin repo
 
 ## interfacing with [external][] tools
 

doc/special.mkd

@@ -46,3 +46,63 @@ Compared to using arbitrary branch names on the same server, this:
 ## delegating access control responsibilities
 
 See [this][deleg].
+
+## #keysonly using pubkeys obtained from elsewhere
+
+If you're not managing keys via the gitolite-admin repo, but getting them from
+somewhere else, you'll want to periodically "update" the keys.
+
+To do that, first edit your rc file and add something like this:
+
+    SSH_AUTHKEYS                =>
+        [
+            'post-compile/ssh-authkeys',
+        ],
+
+Then write a script that
+
+  * gets all the keys and dumps them into `$HOME/.gitolite/keydir` (or into a
+    subdirectory of it).
+
+  * runs `gitolite trigger SSH_AUTHKEYS`.
+
+Run this from cron or however you want.
+
+## #pushhook updating hooks via the admin repo
+
+Gitolite by default maintains the distinction between someone who can push to
+the admin repo and someone who has shell access to the server.  As a result,
+you cannot change any hooks merely by pushing the admin repo.
+
+But some people don't care about this and want to do it anyway.  Besides,
+there *is* one advantage: your hooks can also be versioned now.
+
+So here's how to add/change hooks when you push the gitolite-admin repo:
+
+1.  Put all common hooks in a new directory called 'common-hooks'.
+
+2.  Create a trigger program called 'propagate-hooks' in 'src/triggers' that
+    contains this:
+
+        #!/bin/sh
+
+        cd $GL_ADMIN_BASE
+        cp -a common-hooks/* hooks/common
+
+        gitolite setup --hooks-only
+
+3.  Add this to the `POST_COMPILE` trigger list in the rc file.
+
+And that should be it, pretty much.
+
+If you have lots of repos this is inefficient -- because the hook fixup will
+run on *any* change to the admin repo, even if the change has nothing to do
+with hooks.
+
+If you're concerned about this, put the script in 'src/commands' instead of
+'src/triggers'.  (You might want to add some access control; see other
+commands for inspiration, but it's not really needed in this case).
+
+Then, whenever any hooks have changed, the admin can run
+
+    ssh git@host propagate-hooks