top | item 3056517

Code your own Multi-User Private Git Server

64 points| moomerman | 14 years ago |moocode.com | reply

16 comments

order
[+] X-Istence|14 years ago|reply
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.
[+] moomerman|14 years ago|reply
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.
[+] ajross|14 years ago|reply
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.

[+] davvid|14 years ago|reply
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.

[+] chriseidhof|14 years ago|reply
I use gitosis, and it's very simple to set up and manage. It doesn't feel like overkill at all.
[+] balac|14 years ago|reply
I like Gitolite, it has more fine grained permission control and is pretty simple to get up and running.
[+] Gonzih|14 years ago|reply
I was using Gitosis, now i switch to Gitolite, it's better and simpler.
[+] CodeMage|14 years ago|reply
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.
[+] moomerman|14 years ago|reply
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.
[+] wccrawford|14 years ago|reply
Copying code into a file isn't 'coding'. And it took a lot more than 5 minutes to work all this out.
[+] moomerman|14 years ago|reply
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.

[+] aaronblohowiak|14 years ago|reply
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.

[+] jln|14 years ago|reply
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
[+] Gonzih|14 years ago|reply
Nice education post.