requested by someone who told me it's high time I catered to the experts
too, and saved them some time on the install!
I took the opportunity to streamline the README (especially the "what"
section), and to prioritise the non-root method over the root method in
the install doc.
(thanks to a somewhat heated "discussion" with "abstrakt" on #git)
While I don't agree with everything he said, some improvements are
always possible (always, always!) in docs:
- move the "conventions used" section closer to the action
- add note about RPM/DEB using "gitolite" as the user, not "git"
- de-emphasise multiple gitolite hosting users at the top; refer
advanced users to the already present detailed section later instead
- in that section, add a bit of intro, and hand-wave the inconsistency
between its 2 sub-sections ;-)
----
Unrelated to the "discussion" today, someone else (running Arch? don't
remember) had a system where /usr/local/bin was not in $PATH for a
normal user, so I added a note about that.
Well from now on they will be called "YourName".
Even better quote from essial on #git (after literally typing in
"sitaram.pub" instead of substituting his name as the instructions [in
bold] tell him to do):
come on you know how ubuntu users are
if they see fixed width fonts inside a box they immediately copy-paste it
UBUNTU USERS: I DIDN'T SAY THAT, SOMEONE ELSE DID! For details see
http://colabti.org/irclogger/irclogger_log/git?date=2010-11-04#l2417
[Although, since you apparently are quite happy to use a system that
default installs mono I doubt these little jibes matter to you
anyway...]
[idea: distribute my own pubkey with gitolite and instantly get access
to every gitolite install that is not behind a firewall, anywhere in the
world. No one will notice or realise what I'm doing - MUAHAHAHAHA!!!]
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.
- all anchors prefixed by AUTO_ now
- some bad links fixed (maybe still a few I didn't catch)
- misc wording changes/additions (support section to README,
"technical skills" section to install doc, etc).
