This is an update on gitolite, an ssh-based access control tool for using git in a typical corporate environment. The latest version is always at git://github.com/sitaramc/gitolite.git
While still remaining upward compatible with the "inspiration" project (gitosis), the extra features now form the largest section in http://github.com/sitaramc/gitolite/blob/pu/doc/3-faq-tips-etc.mkd. This was mostly the result of users asking for features they wanted, so please take a look to see if something there strikes your fancy.
[However, the 2 programs that do the actual access control *still*
total only about 90 lines; I firmly intend to keep those less than
100 to make them easy to audit for security.]Significant additions since the last update -------------------------------------------
Installs/upgrades
* The easy install script is also good for upgrades. The new "-q"
option is particularly useful, and makes an upgrade really quick and
"one command". Remote admin mode (where you make config changes in a clone of the
gitolite-admin repo, and push them to the server) is now the
*default*. I think I managed to put enough ssh intelligence into
the ssh aspect to make this finally work without pain, and people on
#git have said it does work (i.e., it's not just me claiming it ;-)Config file maintenance
* Large config files (when you have many, many, repos) can be split up
and delegated to different people. The main config file can give a
specific user the authority to manage a specific group of repos, and
that user can then maintain the access control for those repos
independently. * Config files are also checked for mismatches in pubkeys and
usernames, which is good for catching typos early.Documentation etc
* The documentation, help text, and messages that come out have had
numerous changes based on user feedback on #git. Like in the easy
install script, a lot of effort has gone into the ssh aspect.Other (minor) updates ---------------------
* Supports git installed outside the normal $PATH (on the server).
Without this, *all* your users would have to specify the upload-pack
and receive-pack program paths, either by setting config variables
or using "-u", "--exec" etc. in the clone/push commands. * Trying a plain ssh to your gitolite account now tells you what repos
you have access to, instead of a (largely useless) error message
about needing SSH_ORIGINAL_COMMAND. This sounds like a gimmick...
until you actually need it :) * I've finally started tagging releases, and now an install or an
upgrade done from a clone will record the version number. When you
upgrade, it tells you you're upgrading from version foo to version
bar. * When specifying repos in subdirectories (foo/bar/baz.git) you no
longer have to manually create foo/bar on the server first.Recap of older features (for completeness) ------------------------------------------
* per-branch permissions, including fine-grained control over "rewind" * install without root access on any Unix * simpler but much more powerful config file syntax * more comprehensive logging * "personal" namespace prefix for each user * "deny" rights in the config file (in the "rebel" branch)
Questions and support ---------------------
I'm often on #git, subject to my living in UTC+0530 time, and email is also welcome (sitaramc@gmail.com is preferred, but sitaram.chamarty@tcs.com may get my attention quicker). If you log an issue on github, please also send an email; I am checking github more often now (having missed two issues for many days) but it's not as frequent as I would have liked.
-- Sitaram sitaramc@gmail.com / sitaram.chamarty@tcs.com