F=install 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][http] 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][admin] to administer your gitolite installation).

F=rpmdeb package method

(Unlike in the rest of this document, we use "gitolite" as the "hosting user" instead of "git" here, because that is the user that both the Fedora and Debian packages create. Your distro/OS may vary.)

On your workstation:

On your server, as root:

yum install gitolite    # or 'apt-get install gitolite', or whatever
# this is the only step you need to repeat when upgrading gitolite

# current RPM/DEB create a hosting user called "gitolite"
su - gitolite

# (now as gitolite)
gl-setup /tmp/YourName.pub

Note: please see appendix d for command line options for [gl-setup][].

On your workstation:

git clone gitolite@server:gitolite-admin

F=nonroot non-root method

IMPORTANT WARNING -- IGNORE AT YOUR PERIL: if you want to use this method you had better know the password to the hosting user on the server, or be able to su to it from root, just in case you manage to lock yourself out by messing with the keys.

NOTE: This method is exhaustively described in the tutorial, if you're interested. (That tutorial is by someone else but it's nice enough for me to link it here).

On your workstation:

On your server, as git (the "hosting user"), first check if $HOME/bin is on the default PATH. If not, fiddle with the .bashrc or .bash_profile or similar files and add it somehow. Then:

git clone git://github.com/sitaramc/gitolite
gitolite/src/gl-system-install
# defaults to being the same as:
# gitolite/src/gl-system-install $HOME/bin $HOME/share/gitolite/conf $HOME/share/gitolite/hooks

# to upgrade gitolite, repeat the above commands.  Make sure you use the
# same arguments for the last command each time.

gl-setup /tmp/YourName.pub

Note: please see appendix d for command line options for [gl-setup][].

On your workstation:

git clone git@server:gitolite-admin

F=upgrfromclient upgrading from from-client method to non-root method

Since the from-client method is now deprecated for reasons explained elsewhere, some folks may want to do their next upgrade using the non-root method.

There are many, many ways to skin this cat; here's one way:

F=root root method

On your workstation:

On your server, as root:

git clone git://github.com/sitaramc/gitolite
gitolite/src/gl-system-install
# defaults to being the same as:
# gitolite/src/gl-system-install /usr/local/bin /var/gitolite/conf /var/gitolite/hooks

# to upgrade gitolite, repeat the above commands.  Make sure you use the
# same arguments for the last command each time.

# now create your "hosting user" ('git' in our examples) using whatever
# command your distro expects you to use

# switch to the hosting user
su - git

# (now as git)
gl-setup /tmp/YourName.pub

Note: please see appendix d for command line options for [gl-setup][].

On your workstation:

git clone git@server:gitolite-admin

#upgrade 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.

#insttrouble 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][gl_ssh] and the [ssh troubleshooting][sts] 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][instpath] 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.

#instnameconv 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.

F=instbg helpful background information

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.

F=instrequire requirements

client/workstation

server

technical skills

F=getgl_ getting the gitolite software

You can get the latest version of gitolite from github or google code using the 'git clone' command:

git clone git://github.com/sitaramc/gitolite.git
        # (OR)
git clone https://code.google.com/p/gitolite/

getting a tar file from a clone

If you are on an internal network and cannot clone the gitolite repo, you can do the clone on some other machine and create a tar file from it to use on the internal network. Here's how:

git clone git://github.com/sitaramc/gitolite.git
        # (OR)
git clone git://sitaramc.indefero.net/sitaramc/gitolite.git
cd gitolite
make master.tar
# or maybe "make pu.tar"

Please use the make command as shown, not a plain "git archive", because the Makefile adds a file called .GITOLITE-VERSION that will help you identify which version you are using.

#instappendices_ appendixes

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

#instpath 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.

#clean 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.

#uninstall_ 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.

#gl-setup appendix d: command line options for gl-setup

After gl-system-install (or the RPM/DEB) have installed the code, gl-setup sets up the actual gitolite instance. (Gitolite in [pictures][] may help explain this better.)

In ssh mode, gl-setup expects a pubkey filename the first time it is run, and will complain if you don't supply it. On subsequent runs it is optional; you only need to supply it if you want to quickly and easily change the admin's (or indeed anyone's!) pubkey without going through all the steps that [gl-admin-push][adminpush] requires.

In http mode, gl-setup expects an "admin name" the first time it is run. On subsequent runs, arguments are ignored.

gl-setup accepts the following command line options, which must appear before the pubkey filename/admin name: