Though I gained most of these insights by reading this very informative site, I need to retype things in my own words to catalog my own trials and tribulations while satisfying my own thought process (or lack-thereof). Mind you, I’m not adding much (if anything) to the original post…just my own perspective and tailored to a Dreamhost environment.

Prerequisites

No one likes passwords and all of the baggage attached to them (e.g. typing them, changing them, etc…). To avoid typing passwords when connecting to the server (which becomes a requirement/necessity for git a bit later on) we generate public/private keys using ssh-keygen:

$ ssh-keygen -t rsa -C "user@email.com"

NB: I’m not going to go into the particulars of RSA. Wikipedia has a pretty good primer.

Executing the command generates a sequence of password requests followed by the generated key fingerprint and randomart image (example output shown below with sensitive bits removed and set off by asterisks):

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/username/.ssh/id_rsa.
Your public key has been saved in /Users/username/.ssh/id_rsa.pub.
The key fingerprint is:
*fingerprint*
The key's randomart image is:
*randomart*

You’ll need to move ~/.ssh/id_rsa.pub to the server as it will be needed later in the process.

Setting Up Gitosis

Before starting, it’s important to note 2 things:

1. Wherever you put Gitosis, it will take over the account preventing you from ssh-ing into it directly.
2. When you connect to the repository, the full path to the location where the files are kept is not necessary (and it will fail).

All of the following instructions take place on the server hosting the repository. First, create a src folder to store all the bits of code:

$ mkdir ~/src
$ cd ~/src

Download the latest version of git:

$ wget http://kernel.org/pub/software/scm/git/git-1.7.0.2.tar.gz

Decompress the file:

$ tar -xvvzf git-1.7.0.2.tar.gz

Change to the new directory and install:

$ cd git-1.7.0.2
$ ./configure -prefix=$HOME/local NO_MMAP=1
$ make
$ make install

NB: Your prefix path may be different depending on your preferences. You’ll want to specify the root of the directory that contains (if they currently exist) the bin, lib, and similar directories.

Create a directory to contain localized Python additions.

$ mkdir -p ~/local/lib/python2.4/site-packages

Add these additions to .bashrc and .bash_profile:

# lines for gitosis
export PYTHONPATH=$HOME/local/lib/python2.4/site-packages/
export PATH=$HOME/local/bin:$PATH

Before installing Python setuptools, you can add a .pydistutils.cfg file that adds a bit more fine-grained control to this (and future) installation. You can create this file with your editor-of-choice or by executing the following lines:

$ echo "[install]" >> ~/.pydistutils.cfg
$ echo "install_lib = ~/local/lib/python\$py_version_short/site-packages" >> ~/.pydistutils.cfg
$ echo "install_scripts = ~/local/bin" >> ~/.pydistutils.cfg

The previous lines create a .pydistutils.cfg which looks like this:

[install]
install_lib = ~/local/lib/python$py_version_short/site-packages
install_scripts = ~/local/bin

As an example, in an environment using Python version 2.4.4, libraries would be installed to ~/local/lib/python2.4/site-packages.

After setting up the optional config, install Python setuptools (setuptools-0.6c11-py2.4.egg was the latest version at the time of writing):

$ cd ~/src
$ wget http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c11-py2.4.egg
$ sh setuptools-0.6c11-py2.4.egg

Install the latest version of Gitosis:

$ cd ~/src
$ git clone git://eagain.net/gitosis.git
$ cd gitosis/
$ python setup.py install --prefix=$HOME/local

Using your publickey, initialize Gitosis:

$ gitosis-init < id_rsa.pub

There still remains one minor problem: the permission on the post-update hook:

$ chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

NB: This issue was supposedly fixed with a newer version of setuptools, but I still ran into the issue.

Now, everything should be configured correctly.

Using Gitosis

Gitosis, by default, puts everything into a repositories directory. Git is used to administer Gitosis, so it’s necessary to checkout the Gitosis Admin project. On your local computer:

$ cd ~/your_projects_directory
$ git clone user@domain.tld:gitosis-admin.git
$ cd gitosis-admin

To add a repository or add a user to a group, the file to edit is gitosis.conf. Below is an example configuration:

[gitosis]

# just for initial testing, set the loglevel to DEBUG
loglevel = DEBUG
# if none of the repositories are going to use gitweb
gitweb = no
# if git-daemon isn't running
daemon = no

# the default group
[group gitosis-admin]
writable = gitosis-admin
members = user1

# another user group
[group anothergroup]
# the repository to write to
writable = newrepository
# refers to the previous group and adds another user for just this project
members = @gitosis-admin user2

# a new repository
[repos newrepository]
owner = Some Owner
description = Description of the project

The users refer to the keys in the keydir. If any new users are to be added to the project, their public keys must be added to the keydir and the names added to the appropriate groups in gitosis.conf. Gitosis handles all access control.

Push the new config changes:

$ git commit -am 'Added new group and new repository. Also added new user key.'
$ git push

Everything should work fine. Now to add the new repository.

$ cd ~/your_projects_directory
$ mkdir newrepository
$ git init
$ git remote add origin user@domain.tld:newrepository.git
# add new files, commit, etc...
$ git push origin master:refs/heads/master

The line git push origin master:refs/heads/master is only necessary the first time. Once the link is established, every subsequent push should just entail a git push.

Pitfalls During Installation

After configuring everything, I attempted to create a new repository. This is where I started running into problems:

ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly

The issue was a conflicting line in the authorized_keys file (i.e. an original key that I added to the server to ease the login process).

Then I ran into this problem:

fatal: 'repositories/newrepos.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

I was adding the path repositories without realizing that referring to it was unnecessary.

The biggest issue I ran into, and it was extremely irritating since it returned false positives, was assuming the post-update hook issue was fixed with the latest setuptools. It wasn’t. During a push, it looks like everything is updating fine in git, but no changes are being made on the remote server.

Hope this all was helpful.

I rarely write about coding issues, but it might be a good way to catalog my findings for my own reference. My apologies to everyone else.

Update: I thought this could use an example.

var hashVar = 'content-top';

// ASSERT: hashVar contains the same value as window.location.hash
window.location.hash = hashVar;

// Expected behavior: Window scrolls back to the 'content-top' id
// Demonstrated behavior: Window does nothing

The way that I solved this was to reset the window.location.hash value to an empty string before the reassignment.

var hashVar = 'content-top';

window.location.hash = 'adkcj';
window.location.hash = hashVar;

// Expected behavior: Window scrolls back to the 'content-top' id
// Demonstrated behavior: Window scrolls back to the 'content-top' id

Update 2: Apparently, Firefox, in the latest update, changed the behavior of the hash property. If the value is “zero-ed out”—if you will—the entire page refreshes. I’ve amended the script above so that hash is given a (hopefully) non-id value. Feel free to use a real word, but I didn’t want to take the off-chance of hitting an id I’m using.

Currently Rocking Out To: Jah Work – Ben Harper

Simplicity is not a bad thing. I try to design the way I live. Objects don’t end up in my house unless they have a functional purpose (at least not the objects I buy.) So, I try to model my web apps the same way. Some of the greatest websites are the simplistically functional (check out dictionary.com if you’re looking for a great, recent example how simplicity can improve usability.) I absolutely encourage experimentation and the sharing of ideas and blogs are a great medium to accomplish this. So, by all means, let me know what you think about this issue. I’m not trying to keep anyone from doing cool things, but I am trying to keep the largest number of users in mind.

Currently Rocking Out To: Goodnight and Go – Imogen Heap