In essence, the standard
git: protocol works by having a bidirectional conversation deciding what changesets are available. This is remarkably efficient; in fact, one of git's strengths is its fast checkout. Sadly, the dumb HTTP protocol worked by setting up multiple HTTP connections, one per pack required, with the obvious overhead that that entails.
In addition, the dumb HTTP protocol required an index file, updated by update-server-info hook, in order to be able to access the data. If this hook wasn't configured then the repository couldn't be checked out over HTTP.
The smart git http backend works by providing the standard
git: protocol, provided by one (or a few) HTTP connections to a smart backend, which knows how to provide information from a git repository (with or without the update-server-info information). In addition, the connection provides progress information over the HTTP channel, in much the same way that the
git: protocol works, so the difference between cloning over git and over HTTP is now practically indistinguishable.
Thanks to the hard-working Eclipse webmasters (especially Denis), bug 302353 is now marked as fixed, and all of the Git repositories available via http://git.eclipse.org are now available via
http as well as
ssh. This is great news for those of us who are stuck behind corporate firewalls and can't access either CVS or SVN/git protocols.
At the moment, committer (write) access is available by CVS or SVN only; however, having cloned a read-only repository, it's possible to upload into a different repository by cloning via
http, and then configuring the
url.location.pushInsteadOf to push to a different repository name.
Finally, a couple of Git related notes: firstly, if you haven't bought the excellent Pro Git book you almost certainly should – but it's now also available in ePub format for your iPad. Secondly, the EGit and JGit teams will very shortly be announcing the availability of 0.8.0 coming to an update site near you soon ...
PS since Eclipse Labs doesn't support Git yet, you might want to vote for it, since one of the reasons for Google choosing Hg over Git in the first place was due to lack of speed in their initial analysis at the time.
No sooner than I had written this, than Chris had blogged about EGit and JGit availability, with a link to the new-and-noteworthy for both EGit and JGit. Whilst it is usable, there are some rough edges and missing functionality, which it is hoped to deliver this autumn as part of the 0.9.x release.