Hi Marius, I don't think it is a good idea to drop/deprecate support for ssh or git-proxy. But I do like the approach of having modularized protocols, maybe ssh and git handler should be refactored to its own modules? So one can choose what it wants to install.
Any way, great job! Cheers On Fri, Jun 24, 2011 at 2:40 AM, Marius Mårnes Mathiesen < [email protected]> wrote: > Anyone subscribed to this list will know that installing Gitorious is not > for the faint of heart. There are a lot of moving parts, a lot of > dependencies, and getting everything right is difficult. I really want to > change this. > > One of the things that complicates the setup is that Gitorious is not just > a web app. It's also: > - a service running on top of SSH, using key infrastructure for > authentication and authorization > - a daemon that serves Git repositories over a dedicated protocol (git://) > - a service that provides Git access over HTTP > > Historically, the only protocol that offered write access in Git was SSH. > The git protocol was mainly used because it's faster than HTTP and doesn't > require authentcation over SSH. These two things are the main reasons why > you want to run all these daemons on your server: > - SSH for push > - Git for fast, anonymous pull > > Git's HTTP support changed a lot in version 1.6.6, introducing "smart" > HTTP. It's a fairly simple concept; a modern Git client will (if supported > by the server) open a series of HTTP POST requests to the server, basically > running regular git traffic (upload-pack and receive-pack) over this > connection. This means HTTP got a lot faster, the performance is comparable > to Git over SSH. And since HTTP supports authentication (unlike the Git > protocol) and encryption (SSL), this means you can support all Git usage > scenarios over a single protocol, and stil be safe. Oh, and as a bonus, > people stuck behind a firewall can finally join the party too. > > Gitorious' current HTTP support is based on the old (aka. dumb) HTTP method > (Scott Chacon has a really good write-up on the difference between "smart" > and "dumb" HTTP at http://progit.org/2010/03/04/smart-http.html), which is > slow, error-prone, read-only and locks up your Apache/nginx workers serving > static files. Git itself has a cgi that provides smart HTTP, but making it > work in a scenario where the incoming URL is different from the path on the > file system involves hacking Git itself. > > Christian and I have made a few experiments on implementing smart HTTP for > Gitorious, and this week we've been focusing on one of them: Mutt [1]. Mutt > is a cross breed (and also a git): > - It's written in Ruby > - It runs under JRuby > - It uses the awesome JGit library, which is an implementation of Git in > Java. JGit is used in EGit, the Git support in Eclipse, and in Gerrit, the > code review system used by the Android project > > Mutt will provide anonymous/authenticated fetch/pull and authenticated push > to your Gitorious server. It will be awesome, and it will be installed by a > single command. > > The question is: once we have an easily installed, anonymous/authenticated, > pull/push solution for Git traffic: is it time to deprecate the other > protocol handlers in Gitorious: > - The SSH handler > - The Git handler (git-daemon or git-proxy) > > Would anybody miss them? > > Discuss. > > Cheers, > - Marius > > [1]: https://gitorious.org/gitorious/mutt Yes, I know there's already a > program called Mutt, the name just fits really well. I promise we won't name > the binary mutt, and we won't read your .muttrc. > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
