Re: Smart fetch via HTTP?
- From
A Large Angry SCM <gitzilla@gmail.com>
- Date
- May 15, 2007, 22:30 UTC
- Message-ID
- <464A3471.9070007@gmail.com>
- In-Reply-To
- <20070515201006.GD3653@efreet.light.src>
Jan Hudec wrote:
Show 31 quoted lines
> 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. >
Bundles?
Client POSTs it's ref set; server uses the ref set to generate and return the bundle.
Push over http(s) could work the same...