someone reported an error on "my $_" (presumably old perl) but I now
realise the whole map is useless; both the lists concerned have already
been chomped.
...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!
non-core programs can get their settings from the rc file also.
cpu-time is a perl example and desc is a shell example.
(info is not a good example because it does not use "Gitolite::Easy")
- 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.
- 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.
