The new O'Reilly "Version Control with Git" is freaking amazing. You should definitely check it out! (i.e., purchase it or loan from a friend)
So while I'm learning Git correctly, I've also decided it's time to configure git (as a service) correctly. I started thinking of how I want to serve it. I have many repos, and usually a few people using them (including me).
At first I thought of using git-daemon but it doesn't have encryption (which I love), authentication and so on. It seems more like it would excellent for public read-only repos. That's not what I have.
I thought about HTTP/HTTPS, in which I'll get SSL encryption and I think Git works with HTTP authentications. I wonder if the overhead of HTTPS is higher than SSH. I don't really know. Eitherway, this all feels a bit "hackish" to me.
I can use Gitosis (which has no homepage except the gitweb for the repo of it). I don't know Gitosis and it seems like something I need to dabble in. Don't really have much time for it now. Also, I stray away from projects in Python and Ruby. I have bad experiences from them (really, no offense). At least if I'm running Perl, I have testing coverage and I'll probably be able to debug the problem fast enough, patch it and send the patch along the way.
What remains is.. the way I do it now with SSH. My setup is as follows:
I guess my losing point is that I don't have readonly for these. Maybe if I used extensive POSIX Gecos options I could, but right now I don't. Besides, on a VPS you can't usually have your way with the kernel. I can set up gitweb for each repo to allow viewing or read-only cloning. Meanwhile, I have no need for it. If it's a public project, I'll put it on Github. If not, no one really has "read only" access.
I also have a deployment procedure, but that's probably best left for another post.