This page talks about what you need to make sure you have before you install gitolite. For most people, this is not a big deal, but please read through it anyway. If you want to make sure, there's a section on trying it out safely.
If you're installing gitolite, you're a "system admin", like it or not. Since most people use the ssh mode, ssh is therefore a necessary skill. Please take the time to learn at least enough to get passwordless access working.
You also need to be somewhat familiar with git itself. You cannot administer a whole bunch of git repositories if you don't know the basics of git.
Please make sure you understand at least the following concepts: bare versus non-bare repos, cloning a repo, making changes and committing them, pushing commits to a 'remote', the special remote called 'origin', difference between a fast-forward push and a rewind push, 'refs' (i.e., branches and tags).
It also helps to understand git's hooks mechanism, git-config, and so on.
Some familiarity with Unix and shells is probably required.
Regular expressions are a big part of gitolite in many places but familiarity is not necessary to do basic access control.
Please take note of the following points:
If you're bringing existing repos into gitolite, please see this first.
Gitolite expects all the directories and files it manages/uses to be owned by the hosting user and not have strange permissions and ownerships.
Gitolite does NOT like it if you fiddle with files and directories it cares about in any way except as directed in the documentation.
Gitolite depends on several system-installed packages: openssh, git, perl, sh being the main ones. They should all be configured sensibly and with most of the normal defaults. (For example, if your sshd config says the authorized keys file should be placed in some directory other than the default, expect trouble).
(For your entertainment, here are some requests I have refused over the years).
If you're not sure if gitolite is right for you or your system, it's easy to take it for a trial run, in ssh mode, and play with all of its features (except mirroring). This is very safe, and does not affect anything on your system permanently.
WARNING: this will clobber these files and directories in your
$HOME. Ideally, you should use a throwaway userid.
Just create a throw-away userid, log in to it, then run these commands:
git clone git://github.com/sitaramc/gitolite cd gitolite prove t/ssh*
You will get an error that forces you to read
t/README and set an env var before the test can proceed. This is intentional; I've had people who don't pay attention to the "data loss" warning, and then complain that it was not prominent enough. Forcing them to read a much smaller page appears to focus their attention better!
If it doesn't work, re-read this page to see if you may have missed something that gitolite requires, or ask for support.
If it works, you get a gitolite installation with 7 gitolite users ("admin", and "u1" through "u6").
Don't forget that the client and the server are all on the same user on the same machine; we're simulating 7 gitolite users using ssh keys! (How? Maybe
~/.ssh/config will give you a hint).
URLs look like
user:repo, so for example you can clone the admin repo by
git clone admin:gitolite-admin. Remote commands look like
ssh u1 info.
So start by cloning the admin repo, and try out whatever you want!