Hi, On Tue, May 15, 2007 at 10:10:06PM CEST, Jan Hudec wrote: > Did anyone already think about fetching over HTTP working similarly to the > 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. frankly, I'm not that excited. I'm not disputing that this would be useful, but I have my doubts on just how *much* useful it would be - I'm not so sure the set of users affected is really all that large. So I'm just cooling people down here. ;-)) > 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. How many users really have this problem? I'm not so sure. There are certainly some, but enough for this to be a viable argument? > - 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. You need to have CGI-enabled hosting, set up the CGI script etc. - overally, the setup is similarly complicated as git-daemon setup, so it's not "zero-setup" solution anymore. Again, I'm not sure just how many people are in the situation that they can run real CGI (not just PHP) but not git-daemon. > - 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. Except, well, how do you "set it up"? You need to make sure git-update-server-info is run, yes, but that shouldn't be a problem (I'm not so sure if git does this for you automagically - Cogito would...). I think 95% of people don't set up gitweb.cgi either for their small HTTP repositories. :-) Then again, it's not that it would be really technically complicated - adding "give me a bundle" support to gitweb should be pretty easy. However, this support has some "social" costs as well: no compatibility with older git versions, support cost, confusion between dumb HTTP and gitweb HTTP transports, more lack of motivation for improving dumb HTTP transport... -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
