convenience features

what repos do I have access to?

Sometimes there are too many repos, maybe even named similarly, or with the potential for typos, confusion about hyphens/underscores or upper/lower case, etc. You'd just like a simple way to know what repos you have access to.

Gitolite provides two commands (info and expand) to help you find this information.

support for git installed outside default PATH

The normal solution is to add to the system default PATH somehow, either by munging /etc/profile or by enabling PermitUserEnvironment in /etc/ssh/sshd_config and then setting the PATH in ~/.ssh/.environment. All these are security risks because they allow a lot more than just you and your git install :-)

And if you don't have root, you can't do this anyway.

The only solution till now has been to ask every client to set the config parameters remote.<name>.receivepack and remote.<name>.uploadpack. But telling every client to do so is a pain...

Gitolite lets you specify the directory in which git binaries are to be found, via a new variable ($GIT_PATH) in the "rc" file. If this variable is non-empty, it will be appended to the PATH environment variable before attempting to run git stuff.

Very easy, very simple, and completely transparent to the users :-)

Note: sometimes you have a system that already has an older "git" installed in one of the system PATHs, but you've installed a newer git in some non-standard location and want that picked up. Because of security reasons, gitolite will not prepend GIT_PATH to the PATH variable, so the older git comes first and it gets kinda frustrating!

Here's a simple workaround. Ignore the GIT_PATH variable, and directly set the full PATH in the rc file, like so:

$ENV{PATH} = "/home/sitaram/bin:$ENV{PATH}";

"personal" branches

"personal" branches are great for corporate environments, where unauthenticated pull/clone is a no-no. Since a dev workstation cannot do authentication, even work shared just between 2 devs has to go via the server. This causes the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.

Personal branches exist in a namespace of their own. The syntax is

    RW+ personal/USER/  =   @userlist

where the "personal" can be anything you like (but cannot be empty), and the "/USER/" part is necessary (including both slashes). A user "alice" (if she's in the userlist) can then push any branches inside personal/alice/. Which means she can push personal/alice/foo and personal/alice/bar, but NOT personal/alice.

(Background: at runtime the "USER" component will be replaced by the name of the invoking user. Access is determined by the right hand side, as usual).

custom hooks and custom git config

You can specify hooks that you want to propagate to all repos, as well as per-repo "gitconfig" settings. Please see doc/2-admin.mkd and doc/gitolite.conf.mkd for details.

bypassing gitolite

Sometimes you'll need to access one of the gitolite-managed repos directly on the server, without going through gitolite. Reasons may be some automatic updates or some other ad hoc purposes you can dream up.

Cloning a gitolite-controlled repo is easy enough -- just use the full path (typically ~/repositories/reponame.git) instead of just reponame, to compensate for gitolite not sitting in between and adding those things to the repo path.

But when you push, the update hook (which git will invoke anyway) will fail because it needs all sorts of access control info that it now doesn't have, because the push was invoked without going through gitolite.

In order to bypass the update hook, just set the GL_BYPASS_UPDATE_HOOK environment variable to "1" or something, export it, and push. I prefer not to set that variable permanently, preferring this mode instead:

GL_BYPASS_UPDATE_HOOK=1 git push

gl-admin-push: bypassing gitolite for the gitolite-admin repo: Link

disabling write access to take backups

If you want to take normal, OS-level, backups of the system, you might want git to be quiescent during that time, so that the backup is clean. The best way to do this is to disable write-access to the server for the duration of the backup.

Here's how:

cd $HOME    # if running as "git" user, else "cd ~git" or whatever
echo writes disabled during backup window > .gitolite.down

# << RUN YOUR BACKUP COMMAND(s) HERE >>

rm .gitolite.down

I leave it to you to

make sure that if the backup script fails, the .gitolite.down file is still removed (or not; maybe your policy is that if the backup failed, no further writes are allowed. Whatever...)
if you're extremely paranoid (even I wouldn't worry about this!) make sure that no push is in progress by checking for any git-receive-pack processes in a ps output.