So, yesterday I wrote about some of the great prepared virtual appliances you can get your hands on for no cost at all. One of these is the Turnkey Revision Control server appliance which I wanted to use for a local git installation. The first start up of the appliance was absolutely problem free, however I got into some problems when trying to create my first git repository on the server. And now that I’ve got them all ironed out I thought I’d share them with anyone else who might run into these in the future. I’m guessing that most of you readers out there are interested in the solution to the errors you’re experiencing, there fore I’ll structure this blog post with the errors as section paragraphs.

 

fatal: ‘/git/<repo>’ does not appear to be a git repository

This occurs when you try to clone a repository via the SSH protocol rather than the unsecured git protocol. The reason for this is that the default shell path when your SSH client logs in on the server (which is what happens behind the scenes when cloning via git) is not relative to the path where the repositories are stored. The solution is to adjust the URL so that it is relative to the root of the file system on the git server:

# URL for cloning via git:

git://<turnkeyServerName>/git/<repoName>

# URL for cloning via SSH:

ssh://<user>@<turnkeyServerName>/srv/repos/git/<repoName>

No refs in common and none specified; doing nothing.

This is most likely because when you created the repo you added no items to it before cloning it, hence your git client won’t know what branch to push. Easy solution? Add a first item to the repository before anyone clones it, like so you’ll get a master branch which will be automatically tracked by cloning clients.

 

error: insufficient permission for adding an object to repository database ./objects

You’ll see this when trying to push to your new repository on the server and if your user is lacking write permissions in the .git folder on the server. What worked for me was to move to the .git folder for your specific repository on the server and issue the following commands:

chmod -R g+ws *

chgrp -R <groupName> *

There are of course a million ways to handle file system permissions and this is just one of them, but in the end the error is due to permissions not allowing writes.

 

[remote rejected] master -> master (branch is currently checked out)

Should you encounter this error you’ll probably have seen a quite verbose error message talking about things like “bare repositories” and “receive.denyCurrentBranch”. This error occurs because the repository on the server doesn’t just contain the repository binaries but also a copy of the actual files contained within the repository. It might sound weird, but what it basically means is that the server is set up just like your co workers machine would be and should you push to the repository on the server the working directory (on the server) is going to be very out of sync with the repository. Solution? Well, the first might be to create bare repositories on your server, but I haven’t experimented with that yet so I don’t know. Until then, you could issue the following command (which is also specified in the error message) on your server while in the repository folder:

git config receive.denyCurrentBranch ignore

Your repository isn’t visible in the git web application

To make your repository visible in the git web application (https://<turnkeyServerName>/git) you’ll have to make a file system link with the following command:

ln -s /srv/repos/git/<repoName>/.git /var/cache/git/<repoName>.git

Unnamed repository; edit this file ‘description’ to name the repository.

Now that you’ve managed to get your new repository to show up in the git web application you’ll quickly realize that the default description pops up here. Simplest way to update it? Move to the .git folder for your repository on the server and issue the following command:

echo ‘<description>’ > description

This will change the contents of the description file and replace it with what you echoed out to it.

 
I hope that this is all you’ll need to get started with your new git version control server.

A couple of years ago I evaluated which virtualization platform I would use on my MacBook Pro. I tried  a couple of alternatives, namely: Parallels, VMware Fusion and also VirtualBox. I ended up using VMware Fusion for my virtual Windows machines because I found that some of the integration features with OS X felt a bit tidier than in Parallels.

Yesterday however I found another reason (Turnkey revision control) for using VMware Fusion: there are a lot of prepared appliances out there on the internet ready for use and they are downloadable in a VMware format! I assume that Parallels and its likes have the ability to import VMware disks, but the feeling of just downloading the appliance and clicking the start button without any hassle. Awesome! =)