From: "Shawn O. Pearce" <spearce@spearce•org>
To: "H. Peter Anvin" <hpa@zytor•com>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: More on git over HTTP POST
Date: Sat, 2 Aug 2008 13:57:02 -0700 [thread overview]
Message-ID: <20080802205702.GA24723@spearce.org> (raw)
In-Reply-To: <48938539.9060003@zytor.com>
"H. Peter Anvin" <hpa@zytor•com> 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.
next prev parent reply other threads:[~2008-08-02 20:58 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 21:50 More on git over HTTP POST H. Peter Anvin
2008-08-02 20:57 ` Shawn O. Pearce [this message]
2008-08-02 21:00 ` Daniel Stenberg
2008-08-02 21:08 ` Shawn O. Pearce
2008-08-02 21:23 ` Petr Baudis
2008-08-02 21:32 ` Shawn O. Pearce
2008-08-03 2:56 ` Shawn O. Pearce
2008-08-03 3:27 ` Junio C Hamano
2008-08-03 3:31 ` Shawn O. Pearce
2008-08-03 3:47 ` H. Peter Anvin
2008-08-03 4:10 ` Shawn O. Pearce
2008-08-03 8:10 ` david
2008-08-03 11:42 ` H. Peter Anvin
2008-08-03 11:29 ` H. Peter Anvin
2008-08-03 3:51 ` H. Peter Anvin
2008-08-03 4:12 ` Shawn O. Pearce
2008-08-03 11:31 ` H. Peter Anvin
2008-08-03 4:01 ` H. Peter Anvin
2008-08-03 6:43 ` Mike Hommey
2008-08-03 7:25 ` [RFC 1/2] Add backdoor options to receive-pack for use in Git-aware CGI Shawn O. Pearce
2008-08-03 7:25 ` [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport Shawn O. Pearce
2008-08-03 11:38 ` H. Peter Anvin
2008-08-03 21:25 ` Shawn O. Pearce
2008-08-03 22:16 ` Junio C Hamano
2008-08-04 3:59 ` Shawn O. Pearce
2008-08-04 9:53 ` Rogan Dawes
2008-08-04 10:08 ` Johannes Schindelin
2008-08-04 10:14 ` Rogan Dawes
2008-08-04 10:26 ` Johannes Schindelin
2008-08-04 14:48 ` Shawn O. Pearce
2008-08-04 15:45 ` Rogan Dawes
2008-08-04 15:59 ` Shawn O. Pearce
2008-08-04 16:18 ` Rogan Dawes
2008-08-05 1:03 ` H. Peter Anvin
2008-08-05 1:24 ` Shawn O. Pearce
2008-08-05 1:35 ` H. Peter Anvin
2008-08-05 1:57 ` Shawn O. Pearce
2008-08-05 2:02 ` H. Peter Anvin
2008-08-13 1:56 ` H. Peter Anvin
2008-08-13 2:37 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080802205702.GA24723@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=hpa@zytor$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox