- 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
make it easy to handle syntactic sugar. In summary, compile now calls
parse(sugar('gitolite.conf')).
Details:
- cleanup_conf_line went from subar.pm to common.pm
- explode() and minions went from conf.pm to the new explode.pm
- the callback went away; everyone just passes whole arrays around now
- the new sugar() takes a filename and returns a listref
- all sugar scripts take and return a listref
- the first "built-in" sugar is written (setting gitweb.owner and
gitweb.description)
the new RC file format (of being a hash called %rc) is getting a nice
workout :-)
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 :)
this is pretty slow if you have thousands of repos, since it has to read
and parse a 'gl-conf' file for every repo. (For example, on a Lenovo
X201 thinkpad with 11170 repos and a cold cache, it took 288 seconds).
(With a hot cache -- like if you run the command again -- it took 2.1
seconds! So if you have a fast disk this may not be an issue for you
even if you have 10,000+ repos).
