(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.
- new Gitolite::Easy module hides all the other stuff
- (put GL_ADMIN_BASE and GL_REPO_BASE into %ENV)
- new 'gitolite creator' shell command
- 'writes' command modified to use Gitolite::Easy. It is also the
only dual mode command -- it can be invoked remotely as well as
locally. I deem that the required trick to make other remote-only
commands work locally is too much trouble for what is probably a
rarely used command.
- 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 :-)
new triggers:
- PRE_GIT and POST_GIT in gitolite-shell
- PRE_CREATE and POST_CREATE when a new wild repo is created
- (POST_COMPILE had already existed)
- ACCESS_CHECK triggers both in gitolite-shell and the update hook
- trace() learned to print the file name if called from top level and
a function name is not available
note: trigger was called 'run-all' and only had POST_COMPILE. The code
existed in gitolite-shell, but is now moved to Rc.pm.
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.
The logging is both for paranoia and parsing/automated processing. The
ones you're probably interested in parsing should be easy to pick out
and are very likely to have tab-delimited fields already.
- 'post-compile' subdir moved under 'commands/' but only for
sanity; has no real significance now
- new, internal use only, gitolite command run-all, as in
gitolite run-all POST_COMPILE
which runs all the commands in @{ $rc{POST_COMPILE} } in sequence.
You can sdo this for any section of course, though this is the only
one in the rc right now.
(Future candidates: PRE_GIT, POST_GIT, PRE_CREATE, POST_CREATE)
- 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
Needed when the user didn't actually "install" but is just running it by
using the full path to "gitolite". Without this, every time my code
runs "gitolite <some sub-command>" I have to prefix "gitolite" with
$ENV{GL_BINDIR}, which is kinda painful...
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
The rc file used to be a bunch of variables, each one requiring to be
declared before being used. While this was nice and all, it was a
little cumbersome to add a new flag or option.
If you disregard the "catch typos" aspect of having to predeclare
variables, it's a lot more useful to have all of rc be in a hash and use
any hash keys you want.
There could be other uses; for instance it could hold arbitrary data
that you would currently put in %ENV, without having to pollute %ENV if
you don't need child tasks to inherit it.
----
NOTE: I also ran perltidy, which I don't always remember to :)
