(a few minor doc fixes)

doc/1-INSTALL.mkd

@@ -124,9 +124,10 @@ On your *server*, as *root*:
     # to upgrade gitolite, repeat the above commands.  Make sure you use the
     # same arguments for the last command each time.
 
-    # create your "hosting user" if not already created
-    useradd git
+    # now create your "hosting user" ('git' in our examples) using whatever
+    # command your distro expects you to use
 
+    # switch to the hosting user
     su - git
 
     # (now as git)
@@ -432,6 +433,10 @@ here's how to clean the slate.
         start` and `# gitolite end` inclusive.
       * remove `~/.gitolite`, `~/.gitolite.rc` and
         `~/repositories/gitolite-admin.git`
+      * depending on which install method you used, you may also need to clean
+        out all gitolite files from `/usr/local/bin` or `$HOME/bin`, and then
+        delete `/var/gitolite/conf` and `/var/gitolite/hooks` or
+        `$HOME/share/gitolite/conf` and `$HOME/share/gitolite/hooks`
 
 <a name="_uninstalling_gitolite_completely"></a>
 

doc/gitolite.rc.mkd

@@ -50,20 +50,17 @@ things happen if you change them.
 
     The default UMASK that gitolite uses makes all the repos and their
     contents have `rwx------` permissions.  People who want to run gitweb
-    realise that this will not do.  The correct way to deal with this is to
-    change this variable to `0027` (which gets you `rwxr-x---`), then add the
-    apache or httpd user running the webserver as a member of the 'gitolite'
-    group.
+    realise that this will not do.
 
-    Please note the syntax; the leading 0 is required.  If you change it
-    *after* the install is complete, you'll have to do some chmod's also to
-    adjust permissions of files and directories that have already been
-    created.
+    The correct way to deal with this is to give this variable a value like
+    `0027` (note the syntax: the leading 0 is required), and then make the
+    user running the webserver (apache, www-data, whatever) a member of the
+    'git' group.
 
-    **Note**: if you change this setting on a running gitolite install, you
-    *do* need to run a manual `chmod` on the server to fix up files already
-    created, since umask only affects the permissions on newly created files,
-    not existing ones.
+    If you've already installed gitolite then existing files will have to be
+    fixed up manually (for a umask or 0027, that would be `chmod -R g+rX`).
+    This is because umask only affects permissions on newly created files, not
+    existing ones.
 
 <a name="_variables_with_an_efficiency_performance_impact"></a>
 

doc/hook-propagation.mkd

@@ -123,9 +123,7 @@ there; they're harmless/redundant (TODO)]
 This method was created later, just piggy-backing on everything that already
 existed to cater to the "package" and "root" methods.  In this method, the
 `$GL_PACKAGE_HOOKS` is as accessible or under your control as
-`$HOME/.gitolite`, so it doesn't matter where you put your hooks.  I
-*strongly* suggest putting them in `$GL_PACKAGE_HOOKS` and ignoring
-`$HOME/.gitolite` completely.
+`$HOME/.gitolite`, so it doesn't matter where you put your hooks.
 
 <a name="_when_do_hooks_propagate_"></a>
 

doc/who-uses-it.mkd

@@ -40,7 +40,7 @@ little one-man show!
 He explains his use of it [here][hiren].
 
 [wild]: http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html
-[hiren]: http://ece.uwaterloo.ca/~hdpatel/uwhtml/?p=470
+[hiren]: http://ece.uwaterloo.ca/~hdpatel/uwhtml/wildrepos-in-gitolite/
 
 **Gentoo Linux** has [just moved][gentoo1] their git repositories from gitosis
 to gitolite. There are about 200 repositories, some of them are the so called