I got tired of being told "TL;DR". Now the online versions of most
documents fit on a page or two, or at least most of them do. The rest
has been split out (and you can see the links to the split out sections
right where the text is in the raw Markdown).
This is much more pleasant to read, and I've improved the linking so
it's much less effort for me to keep the links correct.
Normally, I use the word "user" in gitolite to mean *my* users, who are
actually admins on their setups. All my documentation has been geared
to that class of person.
Last night my most famous "user" (not "admin", a real gitolite user)
mentioned that he found it very hard to find info on what a *user* could
do, and he was right. So here goes...
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.
to my eternal shame (considering how proud I am of my documentation)
this was not mentioned anywhere! I'm getting old...
thanks to Pierre Habouzit for catching this
(also slipped in a few other minor doc changes. I wouldn't mix
unrelated stuff in a commit when doing code changes but it seems ok to
do this for docfixes, for some reason).
- 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).
because someone else found the doc overwhelming. However, the suggested
reading order (which so far existed only on the wiki) was probably a
good thing to have at the top of the README, and the disclaimers about
ssh may help keep my sanity a little longer ;-)
there are people who cannot click a "doc/" link on the first google hit,
and think you have to clone the whole thing to see the docs...
I suspect they aren't even hitting the "read more" link that github
shows in the description blurb, or if they go there they aren't even
going to the end of the second para, which contains a nice link.
people will NOT read documentation, especially the bloody install
documentation. I'm about ready to throw in the towel and declare
gitolite unsupported, take-it-or-leave-it.
But I'm making one last attempt to refocus the install doc to better
suit the "I know I'm very smart and I dont have to read docs so it's
clearly your fault that I am not able to install gitolite" crowd.
As a bonus, though, I ended up making proper, hyper-linked, TOCs for
most of the docs, and moved a whole bunch of stuff around. Also finally
got some of the ssh stuff over from my git-notes repo because it really
belongs here.
The wildrepos branch has been merged into master, and deleted. It will no
longer exist as a separate branch. Instead, a new variable
called $GL_WILDREPOS has been added which acts as a switch; when
off (which is the default), many wildrepos features are disabled.
(the "C" permissions, and the getperms (etc.) commands mainly).
Important: if you are using wildrepos, please set "$GL_WILDREPOS = 1;" in
the RC file when you upgrade to this version (or just before you do the
upgrade).
This is actually a pretty big deal, and I am seriously starting wonder
if calling this "gito*lite*" is justified anymore.
Anyway, in for a penny, in for a pound...
This patch implements a generic way to allow access control for external
commands, as long as they are invoked via ssh and present a server-side
command that contains enough information to make an access control
decision.
The first (and only, so far) such command implemented is rsync.
Please read the changes in this commit (at least the ones in conf/ and
doc/) carefully.
Well, something even more outrageous than deny rules and path-based
limits came along, so I decided that "rebel" was actually quite
"conformist" in comparision ;-)
Jokes apart, the fact is that the access control rules, even when using
deny rules and path-limits, are still *auditable*. Which means it is
good enough for "corporate use".
[The stuff that I'm working on now takes away the auditability aspect --
individual users can "own" repos, create rules for themselves, etc.
So let's just say that is the basis of distinguishing "master" now.]
Summary: much as I did not want to use "excludes", I guess if we don't put the
code in "master" it's OK to at least *write* (and test) the code!
See the example config file for how to use it.
See "design choices" section in the "faq, tips, etc" document for how it
works.
- README: add a "what" section first, plus a few minor fixes
- doc/5:
- remove reference to obsolete ml branch URL; point it to the right
place with the right section name
- change text to reflect the fact that p-t-a is now the default!
- added comments to easy install to help do it manually
- README: some stuff moved to tips doc, brief summary of extras
(over gitosis) added
- INSTALL: major revamp, easy install and manual install,
much shorter and much more readable!
plus other docs changed as needed, and updated the tips doc to roll in
some details from "update.mkd" in the "ml" branch
- logs go into $GL_ADMINDIR/logs by default, named by year-month
- logfile name template (including dir prefix) now in $GL_LOGT
- two new env vars passed down: GL_TS and GL_LOG (timestamp, logfilename)
- log messages timestamps more compact, fields tab-delimited
- old and new SHAs cut to 14 characters
