(minor) a slew of little docfixes

doc/2-admin.mkd

@@ -239,6 +239,10 @@ you could set your hooks to only work if a certain "gitconfig" variable was
 set.  Which means we now need a way to specify "git config" settings on a per
 repository basis.
 
+[Note: this feature is disabled by default.  Read the comments around a
+variable called `GL_GITCONFIG_KEYS` in the rc file, then set it to some
+appropriate value, to enable this feature.]
+
 Thanks to Teemu (teemu dot matilainen at iki dot fi), gitolite now does this
 very easily.  For security reasons, this can only be done from the master
 config file (i.e., if you're using delegation, the delegated admins cannot

doc/3-faq-tips-etc.mkd

@@ -534,6 +534,12 @@ to set that variable permanently, preferring this mode instead:
 
     GL_BYPASS_UPDATE_HOOK=1 git push
 
+**WARNING**: Do **NOT** try this with the special `gitolite-admin` repo.  That
+repo also runs a `post-update` hook which needs additional information which
+is NOT available if you bypass gitolite.  Mucking with that repo in this
+manner is strongly discouraged, as in "are you feeling lucky today?".  Use
+`gl-dont-panic` if you need to do some server-side surgery for that repo.
+
 <a name="_INconvenience_features"></a>
 
 #### INconvenience features

doc/admin-defined-commands.mkd

@@ -111,7 +111,7 @@ internal/undocumented/subject to change.
 
 In addition, all the arguments of the command are also available to you, so
 you can define your own command syntaxes.  Gitolite checks these arguments to
-make sure they fit a somewhat conservative pattern (see `$REPOPATT_PATT` in
+make sure they fit a very conservative pattern (see `$ADC_CMD_ARGS_PATT` in
 `src/gitolite.pm`), so take that into consideration when designing your
 commands and usage.
 

doc/delegation.mkd

@@ -36,7 +36,7 @@ an admin from creating access rules for *any* repo in the system -- i.e., set
 limits on what repos he can control.  This would be a nice "security" feature.
 
 Delegation offers a way to do all that.  Note that delegated admins cannot
-create or remove users, not can they define new repos.  They can only define
+create or remove users, nor can they define new repos.  They can only define
 access control rules for a set of repos they have been given authority for.
 
 ----

doc/http-backend.mkd

@@ -1,5 +1,11 @@
 # how to setup gitolite to use smart http mode
 
+**Note**: "smart http" refers to the feature that came with git 1.6.6, late
+2009 or so.  The base documentation for this is `man git-http-backend`.  Do
+**NOT** read `Documentation/howto/setup-git-server-over-http.txt` and think
+that is the same or even relevant -- that is from 2006 and is quite different
+(and arguably obsolete).
+
 In this document:
 
   * <a href="#_WARNINGS_plus_stuff_I_need_help_with">WARNINGS, plus stuff I need help with</a>

src/gl-compile-conf

@@ -282,7 +282,7 @@ sub parse_conf_line
         my ($key, $value) = ($1, $2);
         my @validkeys = split(' ', ($GL_GITCONFIG_KEYS || '') );
         my @matched = grep { $key =~ /^$_$/ } @validkeys;
-        die "$ABRT git config $key not allowed\n" if (@matched < 1);
+        die "$ABRT git config $key not allowed\ncheck GL_GITCONFIG_KEYS in the rc file for how to allow it\n" if (@matched < 1);
         for my $repo (@{ $repos_p })       # each repo in the current stanza
         {
             $repo_config{$repo}{$key} = $value;