"H. Peter Anvin" <hpa@xxxxxxxxx> wrote: > I have investigated a bit what it would take to support git protocol > (smart transport) over HTTP POST transactions. I have started to think about this more myself, not just for POST put also for some form of GET that can return an efficient pack, rather than making the client walk the object chains itself. Have you looked at the Mecurial wire protocol? It runs over HTTP and uses a relatively efficient means of deciding where to cut the transfer at. http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol Most of their smarts are in the branches() and between() operations. Unfortunately this documentation isn't very complete and/or there are some simplifications that the Mecurial team took due to their repository format not initially supporting multiple branches like the Git format does. > The current proxy system is broken, for a very simple reason: it doesn't > convey information about when the channel should be turned around. Well, over git:// (or any protocol that wraps git:// like ssh) we assume a full-duplex channel. Some proxy systems are able to do such a channel. HTTP however does not offer it. > I started to hack on a variant which would embed a VFS-style interface > in git itself, looking something like: > > struct transactor; > > struct transact_ops { > ssize_t (*read)(struct transactor *, void *, size_t); > ssize_t (*write)(struct transactor *, const void *, size_t); > int (*close)(struct transactor *); > }; No, the git:// protocol implementation in fetch-pack/upload-pack runs more efficient than that by keeping a sliding window of stuff that is in-flight. Its I guess two async RPCs running in parallel, but from the client and server perspective both RPCs go into the same computation. HTTP POST is actually trivial if you don't want to support the new tell-me-more extension that was added to git-push. Hell, I could write the CGI in a few minutes I think. Its really just a small wrapper around git-receive-pack. What's a bitch is the efficient fetch, and getting tell-me-more to work on push. -- Shawn. -- 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
