warning against server-side fiddling (<sigh>)

I had someone delete the admin repo on the server, then run gl-setup
again, and complain that included config files did not get restored.

There have been others (see below) before with similar demands, but
those at least had the excuse of being provoked by genuine mistakes.
This guy was intentionally breaking stuff server side.

Wish I could say he was stupid, but actually he was probably smarter
than I.  Just that his idea of the limits of gitolite's responsibility
was vastly different from mine.

----

[1] There was this guy who, as root, went on a "chmod go-rwx" spree for
security, which bollixed up gitweb access to all his repos, so he tells
me gitolite should be able to fix all the permissions on the next admin
push at least?  (That is, instead of just setting umask as it currently
does, it should go on a chmod spree just like he did).

[2] Then there was the guy who told me gitolite should re-create all the
"gl-creater" files for his wildcard repos because he was restoring from
a git push --mirror backup and that doesn't preserve those files?  I
tried to tell him that a git push --mirror doesn't preserve "config" or
"description" or "info/exclude" or any of the other files that git (not
gitolite) maintains, but he didn't care -- losing those did not affect
him (or he never had them), but losing these affected access control,
and it's my fault.

doc/1-INSTALL.mkd

@@ -47,6 +47,11 @@ Please make sure you understand the following points first.
     To make matters worse, ssh problems in gitolite don't always look like ssh
     problems.  See [doc/ssh-troubleshooting.mkd][doc6] for help.
 
+  * gitolite **does NOT** like it when people with shell access to the server
+    fiddle with files and directories it controls.
+
+    Apparently this was not obvious to some people.
+
 A gitolite setup has:
 
   * a server