Merge branch 'master' into pu (only doc updates)

doc/2-admin.mkd

@@ -23,10 +23,12 @@ In this document:
 ### please read this first
 
 Unless you know what you're doing, do not do **anything** manually on the
-server, like adding new repositories or users or changing the access control
-rules.  Things will break.  For example, if you manually create a repo on the
-server, it will not have the required "update" hook, without which there is no
-access control for pushes.
+server (except when the documentation says you should, for example to add
+custom hooks).  In particular, adding new repositories or users or changing
+the access control rules should not be done directly on the server.  Things
+will break.  For example, if you manually create a repo on the server, it will
+not have the required "update" hook, without which there is no access control
+for pushes.
 
 Most normal (day-to-day) gitolite admin work is done by cloning the
 gitolite-admin repo from the server to your workstation, making changes to the

doc/CHANGELOG

@@ -2,6 +2,28 @@ Major changes to gitolite, master branch only, most recent first, no dates but
 the tags can help you position stuff approximately
 [NYD = not yet documented due to lack of time...]
 
+  - v2.0
+
+  - gl-pre-git hook added
+
+  - 'hub' adc added
+
+  - v2.0rc2
+
+*** V1.5.9.1 -- IMPORTANT SECURITY FIX; PLEASE UPGRADE IF YOU'RE USING
+    SOMETHING OLDER THAN THIS ONE
+
+  - supercool new 'git' adc; so cool it's disabled by default
+
+  - '-prune' added to find commands; makes a big diff if REPO_BASE is NFS/CIFS
+    mounted
+
+  - first python ADC contributed -- 'perms' makes setperms etc easier to do
+
+  - 'set-head' ADC added
+
+  - v2.0rc1; major refactor
+
   - v1.5.9
 
   - Nokia MeeGo team contributed ldap scripts

doc/mirroring.mkd

@@ -20,6 +20,15 @@ never *really* lost until you do a `git gc`**.
 
 ----
 
+**Update 2011-03-10**: I wrote this with a typical "corporate" setup in mind
+where all the servers involved are owned and administered by the same group of
+people.  As a result, the scripts assume the servers trust each other
+completely.  If that is not your situation, you will have to add code into
+`gl-mirror-shell` to limit the commands the remote may send.  Patches welcome
+:-)
+
+----
+
 In this document:
 
   * <a href="#_RULE_NUMBER_ONE_">RULE NUMBER ONE!</a>

doc/shell-games.mkd

@@ -36,19 +36,34 @@ clone's `hooks/common` directory, containing the following code:
 
     #!/bin/bash
 
+    [ "$GL_REPO" = "gitolite-admin" ] || exit 0
+
     [ -z "$GL_RC" ] && { echo "ENV GL_RC not set"; exit 1; }
 
     GL_ADMINDIR=`$GL_BINDIR/gl-query-rc GL_ADMINDIR`
 
     cp    $GL_ADMINDIR/local/gitolite.rc    $HOME/.gitolite.rc
     cp -a $GL_ADMINDIR/local/hooks/*        $GL_ADMINDIR/hooks/common
-    $HOME/gitolite-install/src/gl-install -q
 
-Now run easy-install (or gl-setup) once, and you're done.
+    /Full/Path/To/gl-install -q
+        # the path should be the same as that for gl-auth-command in the
+        # "command=" parameter of ~/.ssh/authorized_keys on the server
+
+Don't forget to make it executable!
+
+After this, run the upgrade instructions for the install method you used (just
+as if the `post-update.secondary` file you just created came from a gitolite
+software update).
 
 All future changes to the rc file can be done via local/gitolite.rc in the
 admin repo, and hooks can be added to local/hooks.
 
+**Note**: One quirk of how gitolite [propagates hooks][hpd] is that now this
+`post-update.secondary` exists in all normal repos also.  Just ignore it; it's
+not doing any harm.
+
+[hpd]: http://sitaramc.github.com/gitolite/doc/hook-propagation.html
+
 **Warning**: Nothing in gitolite *removes* hooks, so if you delete (or even
 rename) a script, it still stays on the server -- you'll have to delete them
 manually from the server.