This just seems to be a case of Not Invented Here syndrome. Using gitolite or gitosis would have done the job faster, gives you the ability to have acl's set up per user and all of it uses simple configuration files.

To be fair, the example I have given is simple and you could use something like gitosis or gitolite (I have used them in the past). The point of the article was supposed to be a starting point if you have something else you want to do. For example, I needed to have a fully distributed git backend system across multiple git storage nodes so I needed to learn how I would go about doing that. This post was supposed to give the reader the tools they need to roll their own solution if they want.

For what you are suggestion wouldn't it be simpler to start with a known code base such as gitolite and to then add the modifications you require?

Agreed. Or for small trusted teams any linux box with ssh access will do fine. This is a very well served product area, it really shouldn't be a problem that demands new software development.

Edit: Hah! That's basically what it is, just dressed up with a tiny script and the two-factor trick from last week. Never mind then. This is sane. Just maybe oversold.

NIH or not, I enjoyed reading this post. It showed the simplicity of serving git repos and walked readers through the entire process top to bottom.

Gitolite is a great project and it has many useful features such as branch-level access control. That might be what he meant by "overkill". He simply didn't need those features. I think there's much to be said for keeping things simple.

I use gitosis, and it's very simple to set up and manage. It doesn't feel like overkill at all.

I like Gitolite, it has more fine grained permission control and is pretty simple to get up and running.

I was using Gitosis, now i switch to Gitolite, it's better and simpler.

Gitolite is also well supported. Gitosis is basically an abandoned project. kernel.org's new git infrastructure will be using gitolite which means you can pretty much count on it being supported well into the future.

Don't see why it was necessary to criticize the post so much. True, the title is a bit inadequate, but it's nice to find a combination of several tidbits, tips and tricks combined on one page.

Thanks, I don't understand the criticism either, the feedback via twitter has been quite positive so I will take both on board when writing any further posts.

Copying code into a file isn't 'coding'. And it took a lot more than 5 minutes to work all this out.

Sorry if you find the title misleading, it certainly wasn't intended that way. In fact, sometimes I find it harder to pick the right title than I do to write the blog post.

My intentions were that you could read the article in 5 minutes and the code sample would give you a good starting point to code your own implementation.

So, most of this is based on the ability to specify the command that the user is forced to run in authorized_keys to be a wrapper command that you wrote. This wrapper command reads its arguments and then will execve git shell as appropriate.

What's important to note is that this also talks about SSH_ORIGINAL_COMMAND, which is the environment variable set by sshd when invoking the forced command that is specified in authorized_keys.

Clever hack.

Isn't the point of the D in DVCS that this is supported out of the box? What's wrong with:

  root@server# apt-get install git-core

  git@server$ mkdir ~git/repo.git
  git@server$ git init $!

  user@client$ git remote add origin ssh://git@server/repo.git

Nice education post.