I don't know why I had put VERSION in GL_ADMIN_BASE, which is pretty
stupid. It should be in GL_BINDIR.
It also has nothing to do with setup -- the file needs to be generated
at 'install' time.
...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.
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
- 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.
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.
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...
(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 :)
