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@xxxxxxxxx is preferred, but sitaram.chamarty@xxxxxxx 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@xxxxxxxxx / sitaram.chamarty@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html