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.
More and more people are using one of the first 3 methods of install
(the ones that don't involve running "src/gl-easy-install" from the
client side) usualy due to RPM/DEB being available now.
Previously, the ending message on running that command was serving this
purpose, and so it never really got written down in so many words.
[thanks to antgel for catching this]
----
while we were there, we removed a now-obsolete section that talks about
how to use just one key; there are better methods now
this allows the first part of the repo name (if wildcard repos are
activated) to have a regex like [a-zA-Z0-9]+.
----
Note added by committer:
he assumption used to be that all wildcard repos will have some common
prefix like "users", but I did not imagine it would be like
repo [a-zA-Z0-9]+/users/CREATOR/[a-zA-Z0-9]+
(viz., the "users" is in the middle).
Sounds reasonable...
allows a default 'setperms' string to be set for new wildcard
repositories.
Also, fix a bug in the fork script where a failure in the git command
would still cause the rest of the script to attempt to run.
fixes:
- allow "grouped" admins to get basic info for other users by checking
more than just the *user*'s right to the admin repo
- report_basic is called with a $user argument, but it's not easy
(right now) to propagate this to parse_acl. Use a simple kludge,
(for now at least).
thanks to bcooksley for catching this
This is what I *should* have done back then; thanks to Jeff Mitchell for
pointing out a problem with the old method.
The old one is *definitely* a kludge. <shamefaced grin>
The main use case is for people who give most people access via @all,
which is somewhat unusual but in some situations it probably makes
sense.
See also a related commit made a month or so ago (aa8da93).
Actually these two lint checks were made to help people spot typos in
the config, which sorta becomes meaningless if you have more than a few
such cases anyway, so for most people it should not matter that I am now
merely summarising the number of such cases if there are more then 10.
The log message format has changed. All log messages now have a common
prefix (timestamp, user, IP). This is followed by $SSH_ORIGINAL_COMMAND
(or, in one special case, the name of the user's login shell). Any
further text appears after this (currently this only happens in the case
of a successful push -- one for each ref pushed successfully)
in addition, due to "+" becoming a valid character in a normal reponame,
(think gtk+, etc), the pattern
repo dev/CREATOR/.+
doesn't look like a wildcard repo anymore, so we add an extra check that
if CREATOR is mentioned, it *is* a wildcard.
This has been added *only* to the report_basic function; it doesn't
really matter anywhere else.
see doc/3 for details (look for "separating delete and rewind rights"
----
and for gerrit, this is one more thing it can do that we can too ;-)
[the original text was somewhat misleading. We mean "prevent someone
from creating a branch that they have permissions to push". That is
what is now possible, where it was not possible before.]
It works fine when you're installing off of a tar file because the
Makefile also generates a VERSION file, but when doing from a clone you
still need to generate it.
(plus minor fix to easy install, in the same area of code)
If CGI.pm does not have a user, this patch causes the gitweb
authentication code to assume "gitweb". This allows one to specify ACLs
specifically for gitweb, separately from the @all catch-all.
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: Teemu Matilainen <teemu.matilainen@iki.fi>
Signed-off-by: martin f. krafft <madduck@madduck.net>
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 commits leading up to v1.5 caused the data format to change (we
added a rule sequence number).
This in turn caused a problem for people who may have installed using
the "system install / user setup" mode of install (which includes people
who used RPM/DEB to install it) -- they would now have to *manually* run
"gl-setup" once after the rpm/deb upgrade.
This commit *tries* to mitigate this problem by recording a data format
version number in the compiled output file. On any access to that file,
if the version number is not found or is found to be not equal to the
current version, gl-setup is run again.
The reason I say "*tries*" is that the exact command used to do this is
a bit of a hack for now. However, if it works for Fedora and Debian,
I'm going to leave it at that :)
There has been a format change to the compiled output file. As the
CHANGELOG says:
Upgrading to v1.5 from any version prior to v1.5 requires an extra
step for people who installed gitolite using the "system install /
user setup" method described in doc/0-INSTALL.mkd. For such
installations, after the administrator has upgraded gitolite
system-wide, each "gitolite host" user must run `gl-setup` once
(without any arguments).
This is *not* an issue if you installed using src/gl-easy-install.
There were 2 problems with rule sequencing.
Eli had a use case where everyone is equal, but some are more equal than
the others ;-) He wanted a way to say "everyone can create repos under
their own names, but only some people should be able to rewind their
branches".
Something like this would be ideal (follow the rules in sequence for
u1/u2/u3/u4, and you will see that the "deny" rule kicks in to prevent
u1/u2 from being able to rewind, although they can certainly delete
their branches):
@private-owners = u1 u2
@experienced-private-owners = u3 u4
repo CREATOR/.*
C = @private-owners @experienced-private-owners
RWD = CREATOR
RW = WRITERS
R = READERS
- = @private-owners
RW+D = CREATOR
In normal gitolite this doesn't work because the CREATOR rules (which
get translated to "u1" at runtime) end up over-writing the "deny" rule
when u1 or u2 are the creators. This over-writing happens directly at
the "do compiled.pm" step.
With big-config, this does not happen (because @private-owners does not
get expanded to u1 and u2), but the problem remains: the order of
picking up elements of repo_plus and user_plus is such that, again, the
RW+D wins (it appears before the "-" rule).
We fix all that by
- making CREATOR complete to more than just the creator's name (for
"u1", it now becomes "u1 - wild", which is actually illegal to use
for real so there's no possibility of a name clash!)
- maintaining a rule sequence number that is used to sort the rules
eventually applied (this also resulted in the refex+perm hash
becoming a list)
