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)
[Please NOTE: this is all about *user* groups, not *repo* groups]
SUMMARY: gl-auth-commmand can now take an optional list of usergroup
names after the first argument (which is the username).
See doc/big-config.mkd in the next commit or so
Since it is possible to do all sorts of shenanigans with wildcards and
repo groups, we
- allow only a fragment called "foo" to set permissions for a group
called "@foo", in addition to a repo called "foo"
- forbid defining any groups within a fragment conf. All "@foo = bar
baz" must be done in the main config file now.
If this proves too limiting for anyone I'll worry about it then.
Move the example code from doc/3 to contrib/gitweb/ and modify it
to work with both wildcard and non-wildcard setups.
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
If you have many thousands of repos and users, neatly organised into
groups, etc., the normal gitolite fails. (It actually runs out of
memory very fast while doing the "compile" when you push the config, due
to the number of combinations of repo/user being stored in the hash!)
This commit series will stop doing that if you set $GL_BIG_CONFIG = 1 in
the rc file.
Some notes:
- deny rules will still work but somewhat differently -- now they must
be placed all together in one place to work like before. Ask me for
details if you need to know before I get done with the docs
- I've tested most of the important features, but not every single
nuance
- the update hook may be a tad less efficient now; we can try and
tweak it later if needed but it shouldn't really hurt anything
significantly even now
- docs have not been written yet
