Subject: Smart fetch via HTTP?

From: Jan Hudec <[email-masked]>
Date: Tue, 15 May 2007 22:10:06 +0200

Hello,

Did anyone already think about fetching over HTTP working similarly to the
native git protocol?

That is rather than reading the raw content of the repository, there would be
a CGI script (could be integrated to gitweb), that would negotiate what the
client needs and then generate and send a single pack with it.

Mercurial and bzr both have this option. It would IMO have three benefits:
 - Fast access for people behind paranoid firewalls, that only let http and
   https (you can tunel anything through, but only to port 443) through.
 - Can be run on shared machine. If you have web space on machine shared
   by many people, you can set up your own gitweb, but cannot/are not allowed
   to start your own network server for git native protocol.
 - Less things to set up. If you are setting up gitweb anyway, you'd not need
   to set up additional thing for providing fetch access.

Than a question is how to implement it. The current protocol is stateful on
both sides, but the stateless nature of HTTP more or less requires the
protocol to be stateless on the server.

I think it would be possible to use basically the same protocol as now, but
make it stateless for server. That is server first sends it's heads and than
client repeatedly sends all it's wants and some haves until the server acks
all of them and sends the pack.

Alternatively I am thinking about using Bloom filters (somebody came with
such idea on the bzr list when I still followed it). It might be useful, as
over HTTP we need to send as many haves as possible in one go.

-- 
						 Jan 'Bulb' Hudec <[email-masked]>