From: Tarmigan <tarmigan+git@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"H. Peter Anvin" <hpa@zytor.com>,
git@vger.kernel.org
Subject: Re: Git-aware HTTP transport
Date: Mon, 1 Sep 2008 09:13:42 -0700 [thread overview]
Message-ID: <905315640809010913v56961d41nc397f71f71077e39@mail.gmail.com> (raw)
In-Reply-To: <905315640809010905w20f4ceeo43e7b0a14abd48a3@mail.gmail.com>
(Oops, hit send too early by mistake, so some of my thoughts were incomplete)
On Mon, Sep 1, 2008 at 9:05 AM, Tarmigan <tarmigan+git@gmail.com> wrote:
> On Fri, Aug 29, 2008 at 10:39 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Yet another draft follows. I believe that I have covered all
>> comments with this draft. But I welcome any additional ones,
>> as thus far it has been a very constructive process.
>
> Sorry I'm jumping into this a bit late, but something just occurred to me.
>
>>
>> The updated protocol looks more like the current native protocol
>> does. This should make it easier to reuse code between the two
>> protocol implementations.
>>
>> --8<--
>> Smart HTTP transfer protocols
>
> [...]
>
>> HTTP Redirects
>> --------------
>>
>> If a POST request results in an HTTP 302 or 303 redirect response
>> clients should retry the request by updating the URL and POSTing
>> the same request to the new location. Subsequent requests should
>> still be sent to the original URL.
>>
>> This redirect behavior is unrelated to the in-payload redirect
>> that is described below in "Service show-ref".
>
> I just want to see smart http could support a new feature (please yell
> if git:// already supports this and I am not aware of it). The idea
> is from http://lkml.org/lkml/2008/8/21/347, the relevant portion
> being:
>
> Greg KH wrote:
>>David Vrabel wrote:
>>> Or you can pull the changes from the uwb branch of
>>>
>>> git://pear.davidvrabel.org.uk/git/uwb.git
>>>
>>> (Please don't clone the entire tree from here as I have very limited
>>> bandwidth.)
>>
>> If this is an issue, I think you can use the --reference option to
>> git-clone when creating the tree to reference an external tree (like
>> Linus's). That way you don't have the whole tree on your server for
>> stuff like this.
>
> I do not believe that the server (either git:// or http://) can
> currently be setup with --reference to redirect to another server for
> certain refs, but perhaps with smart http and the POST 302/303
> redirect responses, this would now be possible as a way to reduce
> bandwidth for people's home servers? I have also seen similar
> requests before ("don't pull the whole kernel from me, just add my
> repo as a remote after you've cloned linus-2.6"), so for larger
> projects, it might be a nice feature. Would that be something
> desirable to support?
>
> Would the current proposal be able to support this kind of partial
> redirect? I don't quite see how it would, but it seems very close.
> Perhaps if the show-ref redirect could appear partway through the
> show-ref response and then the client could go off, fetch the some
> refs from that server and then return to the original server for the
> remainder? Or maybe in the upload-pack negotiations, there could be a
> special redirect command as part of the "status continue" response
> that told the client to run off and look for a specific sha at another
> url? Something like
>
> status continue
>
> S: 0014status continue
> S: 0034common <S_COMMON #1>...........................
> S: 0034common <S_COMMON #2>...........................
> ...
I meant to write:
S: 0014status continue
S: 0034common <S_COMMON #1>...........................
S: 0034common <S_COMMON #2>...........................
S: 00xxredirect <WILL_BE_COMMON> <REMOTE_URL>
and then the client could go try the remote url, fetch that SHA and
ancestors, and then resume the upload pack negotiations with
<WILL_BE_COMMON> among the <COMMON> commits. Obviously it's still
somewhat of a half baked idea, and would probably need some kind of
fallback, but does that seem like a reasonable thing to do and a
reasonable way to do it?
>
> Otherwise, it looks very cool, but I have a few more minor questions
> to help my general understanding...
>
>> If the client has sent 256 HAVE commits and has not yet
>> received one of those back from S_COMMON, or the client
>> has emptied C_PENDING it should include a "give-up"
>> command to let the server know it won't proceed:
>>
>> C: 000cgive-up
>
> What does the server do after a 000cgive-up ? Does the server send
> back a complete pack (like a new clone) or if not, how does clone work
> over smart http? Does that mean that if I fall more than 256 commits
> behind, I have to redownload the whole repo? Or am I missing
> something about the the C_PENDING commits being sparse and doing some
> kind of smart back-off (I'm not at all familiar with the existing
> receive-pack/upload-pack)?
>
>> (s) Parse the upload-pack request:
>>
>> Verify all objects in WANT are reachable from refs. As
>> this may require walking backwards through history to
>> the very beginning on invalid requests the server may
>> use a reasonable limit of commits (e.g. 1000) walked
>> beyond any ref tip before giving up.
>>
>> If no WANT objects are received, send an error:
>>
>> S: 0019status error no want
>>
>> If any WANT object is not reachable, send an error:
>>
>> S: 001estatus error invalid want
>
> So again, if the client falls more than 1000 commits behind (not hard
> to do for example during the linux merge window), and then the client
> WANTs HEAD^1001, what happens? Does the get nothing from the server,
> or does the client essentially reclone, or I am missing something?
>
>> (s) Send the upload-pack response:
>>
>> If the server has found a closed set of objects to pack or the
>> request contains "give-up", it replies with the pack and the
>> enabled capabilities. The set of enabled capabilities is limited
>> to the intersection of what the client requested and what the
>> server supports.
>>
>> S: 0010status pack
>> C: 001bcapability include-tag
>> C: 0019capability thin-pack
>> S: 000c.PACK...
>
> Should these be all S: ... ?
Thanks,
Tarmigan
next prev parent reply other threads:[~2008-09-01 16:14 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-26 1:26 Git-aware HTTP transport Shawn O. Pearce
2008-08-26 2:34 ` H. Peter Anvin
2008-08-26 3:45 ` Shawn O. Pearce
2008-08-26 3:59 ` david
2008-08-26 4:15 ` H. Peter Anvin
2008-08-26 4:25 ` david
2008-08-26 4:42 ` H. Peter Anvin
2008-08-26 4:45 ` Imran M Yousuf
2008-08-26 17:01 ` Nicolas Pitre
2008-08-26 17:03 ` Shawn O. Pearce
2008-08-26 4:14 ` H. Peter Anvin
2008-08-26 14:58 ` Shawn O. Pearce
2008-08-26 16:14 ` Shawn O. Pearce
2008-08-26 16:33 ` H. Peter Anvin
2008-08-26 17:26 ` Shawn O. Pearce
2008-08-26 22:38 ` H. Peter Anvin
2008-08-27 2:51 ` Imran M Yousuf
2008-08-28 3:50 ` Shawn O. Pearce
2008-08-28 4:37 ` H. Peter Anvin
2008-08-28 4:42 ` Shawn O. Pearce
2008-08-28 4:58 ` H. Peter Anvin
2008-08-28 6:40 ` Imran M Yousuf
2008-08-28 4:42 ` Junio C Hamano
2008-08-28 14:57 ` Shawn O. Pearce
2008-08-28 17:26 ` david
2008-08-28 17:28 ` Shawn O. Pearce
2008-08-28 17:37 ` david
2008-08-28 17:38 ` Daniel Stenberg
2008-08-28 17:43 ` Shawn O. Pearce
2008-08-28 17:47 ` H. Peter Anvin
2008-08-28 18:04 ` Mike Hommey
2008-08-28 17:43 ` H. Peter Anvin
2008-08-28 18:12 ` david
2008-08-28 18:14 ` H. Peter Anvin
2008-08-28 18:18 ` david
2008-08-29 4:02 ` Junio C Hamano
2008-08-29 5:11 ` H. Peter Anvin
2008-08-29 6:50 ` Junio C Hamano
2008-08-29 17:39 ` Shawn O. Pearce
2008-08-29 19:55 ` Nicolas Pitre
2008-09-01 16:05 ` Tarmigan
2008-09-01 16:13 ` Tarmigan [this message]
2008-09-02 6:06 ` Shawn O. Pearce
2008-09-02 6:09 ` H. Peter Anvin
2008-09-02 6:13 ` Shawn O. Pearce
2008-09-02 18:20 ` Tarmigan
2008-08-28 17:05 ` H. Peter Anvin
2008-08-28 17:10 ` Shawn O. Pearce
2008-08-28 17:20 ` H. Peter Anvin
2008-08-28 17:26 ` Shawn O. Pearce
2008-08-28 17:44 ` H. Peter Anvin
2008-08-28 17:46 ` Shawn O. Pearce
2008-08-28 18:40 ` Nicolas Pitre
2008-08-28 18:47 ` H. Peter Anvin
2013-02-13 1:34 ` Git-aware HTTP transport docs H. Peter Anvin
2013-02-13 2:23 ` Scott Chacon
2013-02-13 15:29 ` Junio C Hamano
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=905315640809010913v56961d41nc397f71f71077e39@mail.gmail.com \
--to=tarmigan+git@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hpa@zytor.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).