...now that triggers are not restricted to external programs and can be
perl code called by gitolite-shell (thus in the same PID), there's no
need to compute and pass along the times() array.
This also changes the arguments to POST_GIT; they're now the same as
PRE_GIT's.
...there was one real bug, plus I had forgotten to put a comented out
line in the rc file, but most of the rest of the effort was moving the
test script over.
oh and I'd also forgotten to move this from 'commands' to 'triggers' :-)
...otherwise 'gitolite help' was getting too confusing, mixing up stuff
that users should not be running directly (even on the server)
----
implementation notes:
those who are worried about the '../triggers/' in various parts of the
code here, remember you can only do that from a command line on the
server. Remote users can only use commands that have been explicitly
listed in the COMMANDS hash in the rc file. This means they can't even
access other commands in the same directory as, say, the 'info' command,
so a '../' is definitely not going to work.
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!
- a remote "id" (usually the IP) is generated and logged on the first
log message in a "transaction"
- speaking of which, a new "transaction ID" is logged that stays the
same for each input command/invocation, tying together all the
spawned commands
- so now time stamps can be generated each time they are needed,
rather than re-use the one at the beginning
- log messages have a keyword at the start now
remote, (create), check1 -- from gitolite-shell
update, check2 -- from update
post-up -- from post-update
command -- from gitolite
die, system -- from anywhere
(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.
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)
