For example, in
repo foo/..*
C = u1 u2 u3
RW+ = CREATOR
RW = WRITERS
R = READERS
config hooks.emailprefix = '[%GL_REPO] '
config foo.bar = bar one
repo foo/u1/..*
config bar.baz = frob nitz
make that last config also work!
(and the other Dan Carpenter finding too, while we're about it!)
Note that neither of these is an actual issue, (and even less likely now
that gitolite is pure perl and no shell metas used) but it's just
playing safe.
- don't look for user-roles if the repo is missing (doesn't make sense
and because we roll in the <perm> = CREATOR function into that, it
causes bugs like [1] below)
- allow ^CREATOR/ in repo names (i.e., don't insist it has to be
/CREATOR/)
----
[1] here's the bug
repo foo/..*
C = u1
RW+ = CREATOR # <--- this line
R = READERS
RW = WRITERS
causes
GL_USER=u2 gitolite info
to print
hello u2, this is gitolite3 (unknown) on git 1.7.7.6
R W foo/..*
R W testing
when in reality it should not be looking at CREATOR at all.
(although the opposite case is still a "die")
We found out how this can happen: if you change
repo r1 r2
to
@g = r1 r2
repo @g
as found by t/deleg-2.t, which suddenly started breaking after an
apparently unrelated commit :-)
when a real repo (i.e., not a groupname or such) doesn't exist, checking
any permission other than ^C will give invalid results unless ^C is ok
for the user in question.
Take a look at this:
repo foo/CREATOR/a[0-9][0-9]
C = u2 u3
RW+ = CREATOR
R = READERS u1
u1 looking for R access on foo/u1/a11 will otherwise result in
success.
implementation notes
- new sugar role_names() to prefix an "@" to CREATOR, and any role
names listed in the rc file.
- invalidate the cache in rules() if the repo was missing. Without
this, an auto-create operation succeeds the ^C check and calls
new_wild_repo(), but then -- due to the cached rules not containing
a rule for CREATOR, the actual read/write fails.
- treat roles (READERS, WRITERS, etc.) as group names that apply only
to that particular repo. Don't add them to %groups, because that
would screw up caching, but add them in when memberships() is called
for the user.
This is why the membership call for the user also has a reponame
tacked on -- i.e., a user's membership list varied depending on
which repo you're talking about.
- while we're about it, pretend we added "CREATOR = <content of
gl-creator>" as another "role". Makes things so much easier dealing
with "RW+ = CREATOR"
- searching for rules pertaining to foo/CREATOR/bar when looking at
repo foo/sitaram/bar is done backwards from what g2 used to do. G2
used to play tricks with the do-eval'd file using global variables
so that what you get after the do may not even contain 'CREATOR'.
We go the other way. We replace sitaram with CREATOR and start
looking for memberships of *both* foo/sitaram/bar and
foo/CREATOR/bar.
- this doesn't work (because we don't know *what* to replace) for
missing repos if GL_USER is not set. This means that 'gitolite
access ...' queries (which do not set GL_USER) cannot be used
reliably for non-existant repos.
Since a ^C check is the only meaningful one for a non-existent repo,
this means you cannot do that from 'gitolite access'.
'GL_USER=luser gitolite info' will still work though ;-)
all in all, much cleaner and simpler than g2.
- usage() gets a little smarter; it now knows what function it was called
from and tries to find a '=for function_name' chunk of data in the script
- the various list-* functions now work off a dispatcher in Load.pm
- (...and they all use the new usage() magic to print their helps!)
- src/gitolite got a lot leaner due to this dispatcher
- src/gitolite-shell became a lot more easier to read/flow
- rc acquired '{COMMANDS}', which gitolite-shell now refers to
- comments in the default rc file changed a bit
- rc got a new REMOTE_COMMAND_PATT (in place of ADC_CMD_ARGS_PATT)
the rest is perltidy and stuff like that
Calling access() changes the CWD to $GL_REPO_BASE!
This causes a problem in the update script -- you're suddenly in the
wrong directory after calling access()!
This is actually happening inside load_1(), so fix that.
(1) testing is very easy, just run this from a clone
t/g3-clean-install-setup-test
BUT BE WARNED THIS IS DESTRUCTIVE; details in t/WARNING
(2) install is equally simple; see 'INSTALL' in the main directory
