As I mentioned before, I want to switch from using Subversion for project code collaboration and versioning to Git.

I’m switching not because I have some idealogical dread of Subversion or its methods. In fact, I quite like how much easier Subversion has made handling code collaboration. The problem I ran into is that Subversion has become doggedly slow and bloated.

For example, a simple project with a current working size of 2.9MB has a Subversion repository that is a massive 98MB in size. Furthermore, it takes a full four minutes to commit a change, even a simple one-line change to a text file. During this commit process, my server’s dual quad-core processors are essentially maxed. Why the repository has become so amazingly large and why the commits take so long, I’ll never know. The maxing out of my server for four minutes per commit is also unacceptable since there are times where minor changes will need to be made to more than a dozen repositories at a time. Multiply the number of commits by 4 minutes a piece, and not only is a terminal on my system tied up for more than an hour, but my server’s CPU is maxed for just as long.

Beginning last week, I dug into Git and learned what I needed to know. The initial impressions are great; however, Git is not without its problems either. The primary problem with Git is that its syntax is extremely-obscure, IMHO.

Subversion was my first version control system, and I only started using it a few months ago. Still, I had no problem setting up remote Subversion repositories, properly setting up read-only and write privilege rules for specific people, getting the repositories to work appropriately, writing automation scripts in Perl that linked into the hooks, and wrapping the whole deal in WordPress to allow for easy management of the repositories and quick access to archives. From my initial playing around with Subversion to having a functional system in use complete with custom code supporting it took maybe two or three work days worth of time.

My progress with Git has been much slower. You might wonder why I’m bothering with Git and not looking elsewhere then. Frankly, I have found that Git has everything I want (speed, lack of redundant file stores, hooks, etc). It also looks like Git can offer some nice enhancements to how we develop projects as branches can be used without having severe performance penalties. The only true problem I’ve found with Git so far is the relatively-large learning curve. Fortunately, I’m just about done with reading, and I’ve learned all the basics I need to know to implement a system I want.

I started with Git by jumping into the wading pool at GitHub. My experience was very good. I highly recommend using GitHub if you have a public project, a private project without specific needs, or just want to try Git out. There are a lot of options at GitHub, and they very nearly had everything I wanted. One of the main limitations at GitHub is the inability for an account to allow other accounts to make repositories for it. For many projects/companies, this won’t be a problem. For us, it is a critical issue. I want to allow certain people to create new repositories, but I don’t want to have to give them “the keys” to the main account in order to allow them to do this.

So, I’m sticking with a self-hosted solution for our repositories since I can code up a clean interface that allows anyone with commit access to create whatever repositories they need. I also gain many other customization advantages this way.

Setting up remote repositories, especially private ones with selective access can be a challenge with the tools that come with Git. In fact, they were so much of a challenge that I gave up on them. I ended up using Gitosis which supports multiple “users” that authenticate using their SSH key and allows for selective repository access for these users.

Since Gitosis doesn’t appear to have any official site, it’s use, just like Git itself, is a bit of a difficult thing to grasp. Fortunately, there are some great tutorials on getting starting with Gitosis. I recommend this Gitosis tutorial as it is the main one that I referred to in order to get everything working.

If this topic looks like it is gaining interest, I’ll probably do some follow up post with more specifics of how I set everything up, what config tweaks I used, and maybe details about my custom interfaces.

FYI: I converted that 98MB Subversion repository to Git using the git-svn tool. The same repository with all the tags and history preserved weighed in at a mere 6.9MB as a Git repository.

I’m playing around with git as a possible replacement for Subversion (svn). I’ll probably blog about my reasons for wanting to switch and also have some tutorials. For now, I wanted to quickly share the fix for a problem I encountered that wasn’t really handled by the documentation.

I set up a bare remote repository to test git out. Everything looked good as I got this going, but then I hit a big snag.

When I tried to push the local repository back to the remote repository, I received the following error:

I have to say that this was completely unexpected as I had followed tutorials in the official documentation up to this point. None of the steps said anything about a “project description file” nor about new bare repositories requiring additional setup in order to be pushed to.

Fortunately, this problem wasn’t difficult to fix. There is a file inside the bare repository’s root called description. I simply modified this file and the next time I pushed the changes, it worked like a charm.

If your bare repository is in ~/projects/test.git, you would do the following:

1. Modify the description file:
   vi ~/projects/test.git/description
2. Delete the existing text:
   Unnamed repository; edit this file to name it for gitweb.
3. Put whatever description you want for the repository in the file:
   My Really Awesome Project
4. As always, save the file and close vi.

Now you can push without this nasty error hanging you up.

As a side note, the developers of git have a hosted git solution that is really cool. It’s called github, you should check it out.