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 <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
