(regularly updated)

Installing Git on a shared hosting account is simple, the installation is fast and like most things Git, it just works.

As with my previous Subversion on shared hosting post, this will be a barebones install. The purpose of this installation is to be able to push changes from remote repositories into the hosted repo, where the hosted repository may also serve as the source directory of the live website. Like this.

Prerequisites

The only two things you absolutely must have are shell access to the account and permission to use GCC on the server. Check both with the following command:

$ ssh joe@webserver 'gcc --version'
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
[...]

If GCC replies with a version number, you should be able to install Git. SSH into your server and let’s get started!

If you see something like /usr/bin/gcc: Permission denied you don’t have access to the GCC compiler and won’t be able to build the Git binaries from source. Find another hosting company.

Update your $PATH

None of this will work if you don’t update the $PATH environment variable. In most cases, this is set in .bashrc. Using .bashrc instead of .bash_profile updates $PATH for interactive and non-interactive sessions–which is necessary for remote Git commands. Edit .bashrc and add the following line:

export PATH=$HOME/opt/bin:$PATH

Be sure ‘~/opt/bin’ is at the beginning since $PATH is searched from left to right; to execute local binaries first, their location has to appear first. Depending on your server’s configuration there could be a lot of other stuff in there, including duplicates.

Double-check this by sourcing the file and echoing $PATH:

$ source ~/.bashrc
$ echo $PATH
/home/joe/opt/bin:/usr/local/bin:/bin:/usr/bin

Verify that the remote path was updated by sending a remote command like this (from another connection):

$ ssh joe@webserver 'echo $PATH'
/home/joe/opt/bin:/usr/local/bin:/bin:/usr/bin

Note: Installing into the ~/opt directory keeps the home folder cleaner and is where add-on applications are customarily installed on Unix systems.

Installing Git

SSH into your webserver. I created a source directory to hold the files and make cleanup easier:

$ cd
$ mkdir src
$ cd src

Grab the most current source tarballs from the Git site. At the time this post was last updated, the most recent version was v1.7.6:

$ curl -LO http://kernel.org/pub/software/scm/git/git-1.7.6.tar.bz2

Untar the archive and cd into the new directory:

$ tar -xjvf git-1.7.6.tar.bz2
$ cd git-1.7.6

This next step is the only one that really seems to matter with regards to shared hosting. The Configure script needs to be told where to install, and because we’re on a shared host, Git’s files should be put somewhere in our home directory:

$ ./configure --prefix=$HOME/opt
[words...]

Lastly, make and install:

$ make && make install
[lots of words...]

That should be it, check your installed version like this:

$ git --version
git version 1.7.6

It's now safe to delete the src folder which contained the download and source files.

Note that these instructions do not install Git's documentation man pages. Also, these instructions appear to work exactly the same on Mac OS X, though the installer package is way easier and includes documentation.

My preferred shared hosting providers are A2 Hosting and WebFaction.

For some reason I’ve put off setting up SSH key pairs, probably having something to do with how arcane most of the setup instructions appear. Tonight however, I’m unexpectedly preparing to transfer a client to a new hosting account on Media Temple and enjoying key-pair access to their new repository.

Media Temple doesn’t yet support svn:// access to Subversion repositories, only svn+ssh://. So, having been pushed, I finally decided to make my life easier with SSH key pairs.

The best tutorial I found was Allan Odgaard’s: Subversion support and ssh key pairs. Without ssh key pairs, all the fantastic Subversion integration in TextMate won’t work with svn+ssh:// repositories.

However there’s one crucial piece of information missing from that: Permissions.

If access to the SSH configuration files is not properly assigned, the ssh pair won’t work. No meaningful errors at connect time, just silent, infuriating failure.

The ~/.ssh directory permissions need to be set to 0700 and the authorized_keys file needs to be set to 0600:

chmod 0600 ~/.ssh/authorized_keys
chmod 0700 ~/.ssh

If group or world have write access to authorized_keys, key pair authentication will fail.