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.
this happens when users are given rights to a repo via a groupname, and GL_BIG_CONFIG is in effect
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.]
...for some or all repos (and a minor bug fix in the adc.common-functions file)
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 <firstname.lastname@example.org> Cc: Teemu Matilainen <email@example.com> Signed-off-by: martin f. krafft <firstname.lastname@example.org>
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.
…lease read) 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.
This reverts commit 9612e3a, since it is no longer needed as of the rule sequencing changes we just made. Conflicts: src/gl-compile-conf
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)
skipping gitweb/daemon has an enormous impact on speed of an admin-push!
[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.