helpful background information

gitolite runs as a single (real) user on a server, and is invoked via ssh. Traditionally, this "hosting user" is "git", and thus all git URLs start with ssh://git@server (or the equivalent shorter form git@server:).
- RPM/DEB create and use "gitolite" as the hosting user
- there is usually only one hosting user per server (machine), but gitolite makes it trivial to have as many as you want. In fact, every user on the server is a potential hosting user.
using this single user and sshd (or httpd) authentication, gitolite allows you to create any number of "virtual" users. Virtual user names only mean something to gitolite, and they need not be the same as any real userid on the server or any of the clients accessing it.
- the first such virtual user is the "admin user", created during the install sequence.
gitolite depends heavily on ssh pubkey (passwordless) access. Do not assume you know all about ssh -- most people don't. If in doubt, use a dedicated userid on both client and server for installation and administration of gitolite.

To make matters worse, ssh problems in gitolite don't always look like ssh problems. See the ssh troubleshooting document for help.
gitolite does NOT like it when people with shell access to the server fiddle with files and directories it controls.

Apparently this was not obvious to some people.

It is possible to have the server and the client be the same machine, and even the admin user be also the hosting user, (i.e., sitaram@server can install and administer a gitolite setup running under sitaram@server, a situation that is common with some hosting services). It's actually fairly easy and safe to do, as long as you have password access to the server for emergency use. However, I will not be documenting it because (a) if you know ssh you'll know how to extrapolate my instructions to do this and (b) if you don't know ssh it'll be a nightmare to support you.