master TOC | chapter TOC | support

gitolite installation

(Note: git servers are most commonly used with ssh URLs, and this document describes installing gitolite to support such usage. If your users prefer http URLs, read this to install gitolite to support "smart http").

installing and upgrading gitolite

This section tells you how to install/upgrade gitolite, without too much background. Later sections have more details and troubleshooting info; please read them before asking for help if you have problems.

A bare minimum gitolite setup has:

Gitolite allows 3 methods of install. The two most common are (1) the package method, used if you have a gitolite RPM or a DEB available, and (2) the non-root method which is the preferred manual install mode. Less commonly used is (3) the root method, which is useful if you plan to have multiple "hosting users" on the same server.

These install methods are described in detail below. (Once you finish the install, read the admin document to administer your gitolite installation).

package method: Link

non-root method: Link

root method: Link

upgrading

Upgrading is easy; you just re-run some of the same commands used for install. These commands are clearly noted in the install instructions above.

However, if you've added any new hooks, you must also run the next step (the gl-setup command), although this time you don't need to supply a pubkey filename as an argument.

install trouble?

If you run into trouble, please read the following sections.

common install problems

The most common problem is usually ssh. Here are three facts of ssh:

Please read how gitolite uses ssh and the ssh troubleshooting documents before asking for help.

If you've tried multiple methods of install, you may have multiple copies of the sources lying around. This could be a problem; see appendix a for how to detect and deal with this.

If none of this works read the rest of this document, understand it as much as you can, then ask for help.

naming conventions used

Throughout the documentation, we use "YourName" as the admin user, and his workstation is called "client". The hosting user is "git", and the server is called "server". Please substitute your values as needed.

If you're using DEB or RPM, the installer creates a user called "gitolite", so substitute that for "git" anywhere in the docs where the "hosting user" is mentioned as "git".

Also, we often say "the rc file". This means ~/.gitolite.rc on the server. And when we say the "access control rules", or "conf file", or "config file", we mean conf/gitolite.conf on your gitolite-admin clone.

helpful background information: Link

requirements: Link

getting the gitolite software: Link

appendixes

The following sections have some miscellaneous information that does not cleanly to fit anywhere else.

appendix a: PATH issues for gl-setup

If you've tried multiple methods of install, you may have multiple copies of the sources lying around, and when you ran gl-setup it picked up the wrong one. This might also happen if the directory you supplied as the first argument to gitolite/src/gl-system-install is not even in the $PATH.

Run su - git then which gl-setup to see which it picked up. This is what it should be for each method:

If this is not what you get, remove the partially installed or extraneous sources, if any, and try again. Or fix your $PATH.

One situation that is not easy to solve is if the system admin installed gitolite using the RPM/DEB or root methods, and you want to install a later version using the non-root method. Since /usr/bin and /usr/local/bin are usually earlier than $HOME/bin in the $PATH, you'll have to get creative. Good luck.

appendix b: cleaning out a botched install

When people have trouble installing gitolite, they often try to change a bunch of things manually on the server. Or sometimes they'll upgrade from one install method to another without checking some things over properly. Or they'll follow instructions meant for a much newer version of gitolite and make a royal mess of the whole thing.

Here's how to clean up, without losing your actual repositories.

All this is on the server. Note that the instructions are so long because they're generic enough to fit any situation.

That should do it.

appendix c: uninstalling gitolite completely

To uninstall gitolite completely, first follow the "clean out..." steps in the previous section.

If you have not really started using gitolite properly yet, you can remove all of ~/repositories also and be done.

But if you do need to preserve the other repos and wish to continue to use them, remove all the update hooks that gitolite installs in each repository. The easiest way is:

find ~/repositories -wholename "*.git/hooks/update" | xargs rm -f

but you can do it manually if you want to be careful.