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

This is a basic install without documentation. My main goal is to be able to push changes from remote repositories into the hosted repository, which also serves 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 will not 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/bin:$PATH

Be sure ‘~/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/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/bin:/usr/local/bin:/bin:/usr/bin

Note: Previous iterations of this page installed into the ~/opt directory. Following current Git conventions, I’m now installing into the default ~/bin.

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 recent source tarball from Github. When this post was updated, the current Git release was version 1.7.10.1:

$ curl -LO https://github.com/git/git/tarball/v1.7.10.1

Untar the archive and cd into the new directory:

$ tar -xzvf v1.7.10.1
$ cd git-git-9dfad1a

By default, Git installs into ~/bin which is perfect for shared hosting. Earlier versions required adding a prefix to the configure script (like this), but none of that is necessary anymore. If you do need to change the install location of Git, just specify a prefix to the Make command as described in Git’s INSTALL file.

With all that taken care of, installation is simple:

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

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

$ git --version
git version 1.7.10.1

It's now safe to delete the src folder containing the downloaded tarball and source files.

My preferred shared hosting providers are A2 Hosting and WebFaction.

Here is the process I used to automatically remove a lot of those duplicates and import the remainder into the Mac’s Address Book.

The first step is to get out of Palm Desktop as soon as possible. Select all contacts and export to a group VCard. This one was 3.4 MB.

Most of this will happen in Terminal, but a quick stop in BBEdit or TextWrangler will save a few steps later on. (TextMate tends to choke on big, non-UTF files.) The Palm export file is encoded in MacRoman. It’s 2008, pretty much any text that isn’t Unicode should be. I used TextWrangler to convert the encoding to UTF-8 no BOM (byte order marker).

VCards require Windows style CRLF line endings. While we could deal with those in Sed, we might as well just switch the file to Unix style LF endings in TextWrangler too. The TextWrangler bottom bar should switch from this:

To this:

Now comes the magic.

While this could be done as an impossible-to-read one-line sed command, it’s easier to digest and debug as separate command files.

Here are the steps:

1. Use Sed to join each individual VCard into a single line using a token to replace line feeds, output to intermediate file
2. Sort and Uniq the result to remove obvious duplicates.
3. Replace the tokens with line feeds

Below are the two sed command files I used. I ran these individually but they could easily be piped together into a one-line command.

vcard_oneline.sed:

# define the range we'll be working with
/BEGIN:VCARD/,/END:VCARD/ {

# define the loopback
:loop

# add the next line to the pattern buffer
N

# if pattern is not found, loopback and add more lines
/\nEND:VCARD$/! b loop

# replace newlines in multi-line pattern
s/\n/   %%%     /g
}

Run that like this:

sed -f vcard_oneline.sed palm_dump.vcf > vcards_oneline.txt

Then run that file through sort and uniq:

sort vcards_oneline.txt | uniq > vcards_clean.txt 

vcard_restore.sed:

# replace tokens with DOS style CRLF line endings
s/      %%%     /^M\
/g

# add the <CR> before the LF at the end of the line
s/$/^M/

Run that with something like this:

sed -f vcard_restore.sed vcards_clean.txt > vcards_clean.vcf

After that last step, you should be able to drag the vcards_clean.vcf file into Address Book to import your vcards.

Suggestions for improvement are always welcomed.

Notes:

In VIM, type the tab character as control-v-i (hold control while pressing v then i), type the line break by typing control-v-enter.

iconv could be used to convert from MacRoman to UTF-8. TextWrangler just seemed easier at the time.

Palm Desktop appears to dump group VCards in input order, so duplicate entries were not grouped together. Running the output through sort visually reveals a ton of duplicates and makes it possible to use uniq to remove consecutive duplicates.

I had to quit and re-open Address Book once or twice before it would import the files.

But LiquidWeb doesn’t offer Subversion. And I will no longer do web work without it.

For some time I’d been considering leaving LiquidWeb because the lack of svn was now hindering work on my own sites. For the same reason, I’ve had to pass them over several times when clients asked for hosting recommendations. Then the other night, I stumbled across a discussion about installing Subversion on a shared host. Why didn’t I try that years ago?

Installation Instructions

These instructions assume basic proficiency with the Unix command line. Note that the goal is to install the SVN client, plan on hosting your repositories somewhere else.

Connect to your account with ssh and create a working directory, mine’s called _src:

cd
mkdir _src
cd _src

Next, use wget to pull down the subversion sources. You could also use curl, but wget does the same with less typing. Choose a version from this list of Subversion sources. The parallel “subversion-deps” download includes all dependent sources required to build Subversion.

wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz

Next, untar the sources and dive into the directory:

tar -xzvf subversion-1.4.6.tar.gz
tar -xzvf subversion-deps-1.4.6.tar.gz
cd subversion-1.4.6

One step, maybe (32-bit?)

At this point, depending on your server configuration, you might be able to install with the following two commands:

./configure --prefix=$HOME --without-berkeley-db \
     --with-ssl --with-editor=/usr/bin/vim \
     --without-apxs --without-apache
make && make install

That worked on some servers but not others, I spent many hours clumsily trying to figure out why. I found that the build process was linking to external libraries instead of the ones in subversion-deps, despite the configure directives.

On the 64-bit server (x86_64) this was a big problem, even though everything worked normally on two 32-bit (i686/i386) servers. Check server architecture with either arch, uname -a or cat /proc/cpuinfo. The solution for 64-bit machines is to build the three main components beforehand and then tell Subversion where to find them.

Build them, use them (64-bit?)

The following commands systematically build each of the three shared libraries from the Subversion-deps sources. This should guarantee that the files Subversion links to will be compatible. In each step, we explicitly enable compilation of shared libraries and prefix the files into our home directory. This looks worse than it is.

Build apr, apr-util and neon, in that order:

cd apr
./configure --enable-shared --prefix=$HOME
make && make install

cd ../apr-util
./configure --enable-shared --prefix=$HOME \
     --with-expat=builtin --with-apr=$HOME \
     --without-berkeley-db
make && make install

cd ../neon
./configure --enable-shared --prefix=$HOME \
     --with-libs=$HOME --with-ssl
make && make install

With those out of the way, we can now configure and build Subversion. According to the notes in Subversion’s configure file, the --with-ssl flag is not necessary since it’s just passed to neon and we already built neon. --without-apxs and --without-apache prevent Subversion from trying to install its Apache modules. Remember to point to the libraries we just built (in $HOME): (note: you may need to add the --without-serf flag as well, see this comment)

cd ../
./configure --prefix=$HOME --without-berkeley-db \
     --with-editor=/usr/bin/vim --with-apr=$HOME \
     --with-apr-util=$HOME --with-neon=$HOME \
     --without-apxs --without-apache
make && make install

Subversion should now be installed! It’s likely you already have :~/bin in your user $PATH, if so, you can try it out right away:

svn --version

   svn, version 1.4.6 (r28521)
      compiled Jan 29 2008, 11:05:47

So far, I’ve run this against two LiquidWeb shared accounts, one LiquidWeb CPanel container on a VPS and a HostingMatters shared account running JailShell. After some limited testing accessing different repositories with https and svn+ssh, everything seems to be working.

Now I just need to figure out where to put my repositories, here are some free Subversion hosts I’ve used or are considering:

• Beanstalk 20 MB free
• Assembla 500 MB free?! really?
• Unfuddle 15 MB free
• Google Code 100 MB free, must be open source

Two other sites which aren’t free, but I’m keeping in mind for the future: Wush and Project Locker.

The getting there was the hardest part

While I was finally able to streamline this down to a fairly simple process, it was not easy to get there. I don’t do much compiling from source, so I’m very clumsy about troubleshooting. If any of these steps can be simplified, please leave a note.

Here are some of the errors I saw along the way:
/usr/lib/libexpat.so: could not read symbols: File in wrong format
/usr/lib/libexpat.so: could not read symbols: Invalid operation
/home/joe/_src/subversion-1.4.6/neon/src/.libs/libneon.a: could not read symbols: Bad value 

The first two errors indicate that the build had grabbed the 32-bit libexpat from /usr/lib instead of the 64-bit version from /usr/lib64. However, redirecting to the 64-bit libraries introduced other problems such as the libneon.a bad value error. As mentioned above, what I needed to do was pull libraries from the subverson-deps code. To use those, I needed to compile each one first.

Resources:

• Subversion’s INSTALL file
• ./configure -help
• These commands, from this original post almost worked.
• Installing Mephisto and Subversion on a Shared Host, first inkling this was possible
• similar problem with with /usr/lib instead of /usr/lib64.
• GATTAGA’s post was the first clue about working around the libexpat problem.
• SVNforum: libneon.a: could not read symbols: Bad value This was the post that gave me the final bit of information I needed

Related: How to install Git on a shared host

Update, November 2010: Sometime this year Liquid Web disallowed compiler access. I now host my sites at WebFaction and A2 Hosting.

-i extension
   Edit files in-place, saving backups with the specified extension.
   If a zero-length extension is given, no backup will be saved.  It
   is not recommended to give a zero-length extension when in-place
   editing files, as you risk corruption or partial content in situ-
   ations where disk space is exhausted, etc.

This doesn’t work:

sed -i -e's/apples/oranges/' file.txt

The key thing here is that the extension after the -i flag is not optional. If you leave it off, sed assumes you’ll be entering it via stdin, which isn’t allowed and yields this error:

sed: -i may not be used with stdin

The solution is to send a zero-length extension like this:

sed -i '' -e's/apples/oranges/' file.txt

Careful with this, it could be really dangerous with poorly crafted commands.

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.

It’s an open source server supporting full read-write calendars, availability blocking, delegations, notifications, directory integration and more. I’m going to be setting up a few of these once we start migrating to Leopard.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

–Brian Kernighan

Another fantastic quote attributed to Mr. Kernighan that applies to making most anything:

“Controlling complexity is the essence of computer programming.”

Many other useful insights here: Basics of the Unix Philosophy Scroll down to the rules and extend these beyond just Unix or programming.

Since this was all rooted in Unix, here’s a document I wish I’d read before first wading into the OS X terminal way back when: Learn UNIX in 10 minutes.

So we basically needed to delete the contents of a small file, “deleteme.txt” from the contents of larger file, “masterlist.txt”. The lines to remove were not contiguous and some lines in the smaller file might have already been removed from the larger file.

Here is the piped unix command I used to do this:

cat deleteme.txt deleteme.txt masterlist.txt | sort | uniq -u > newmasterlist.txt

The uniq command’s -u flag outputs only lines which appear once, omitting every duplicate line. I used cat to join the deleteme.txt file twice to guarantee the interim file would contain at least two copies of every line to remove. If the lines already appeared in masterlist.txt, then there would be three to remove, but forcing duplicates made sure I wouldn’t end up with the already deleted lines being added back in (an XOR).

As I wrote this out, it started to seem more and more simple, almost to the point of silly. Writing this post took far longer than fixing the files. But the solution didn’t occur to me right away and this post is now exactly what I was googling around for.