Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Martin Fick
The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might

Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Junio C Hamano
Martin Fick mf...@codeaurora.org writes: The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer.

Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Stefan Beller
On Thu, Apr 2, 2015 at 3:18 PM, Martin Fick mf...@codeaurora.org wrote: The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be

Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Stefan Beller
After looking at $gmane/264000 again, maybe the client should talk first stating all the relevant information it wants to get, though I realize this is not part of capabilities so maybe it could even before, such as: Client: All I want to do is an ls-remote, so only Phase 2, no transmission of

Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Duy Nguyen
On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano gits...@pobox.com wrote: This is a follow-up on $gmane/264553, which is a continuation of $gmane/264000, but instead of giving two required readings to readers, I'll start with reproduction of the two, and add a few more things the current

Re: [PATCH] protocol upload-pack-v2

2015-04-02 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano gits...@pobox.com wrote: This is a follow-up on $gmane/264553, which is a continuation of $gmane/264000, but instead of giving two required readings to readers, I'll start with reproduction of the two, and add

Re: [PATCH] protocol upload-pack-v2

2015-03-31 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: I have a feeling that it is a bit too premature to specify the details at such a low level as capaiblities are announced by prefixing four-byte 'c', 'a', 'p', ':' in front and a multi-record group has its element count at the beginning (or an end

Re: [PATCH] protocol upload-pack-v2

2015-03-10 Thread Kyle J. McKay
On Mar 9, 2015, at 18:38, Duy Nguyen wrote: A minor point on capability negotiation. I remember why I passed capabilities via command line instead of this proposal. With this proposal, daemon.c does not recognize i18n capability and cannot switch to the correct language before it reports an

Re: [PATCH] protocol upload-pack-v2

2015-03-09 Thread Duy Nguyen
A minor point on capability negotiation. I remember why I passed capabilities via command line instead of this proposal. With this proposal, daemon.c does not recognize i18n capability and cannot switch to the correct language before it reports an error. But perhaps I approached it the wrong way.

Re: [PATCH] protocol upload-pack-v2

2015-03-08 Thread Junio C Hamano
Stefan Beller sbel...@google.com writes: I do not see a good reason why we want I am sending N caps upfront, instead of this, that, and here is the end of the group. I thought about having an end marker, so something like capabilities start thin-pack lang ofs-delta capabilities done

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Duy Nguyen
On Sat, Mar 7, 2015 at 6:38 AM, Stefan Beller sbel...@google.com wrote: +Reference Discovery (v2) + + +In version 2, reference discovery is initiated by the client with +want-refs line. The client may skip reference discovery phase +entirely by not sending want-refs

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Duy Nguyen
I'm still wondering if we should reserve more from the packet length. We have used length for pkt-flush. Shawn pointed out that we still have 0001, 0002 and 0003 but we may use some of them to avoid abuse of pkt-flush in some cases. Perhaps we could limit packet length to 0xfff0, so we have

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Stefan Beller
On Fri, Mar 6, 2015 at 3:38 PM, Stefan Beller sbel...@google.com wrote: From: Duy Nguyen pclo...@gmail.com Oops. I edited the proposal from Duy heavily(?), such that it is different from what he proposed 4 days ago. In my impression this is what most of the participants would agree on. -- To

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Junio C Hamano
Stefan Beller sbel...@google.com writes: @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport Noise? @@ -124,9 +130,56 @@ has, the first can 'fetch' from the second. This operation determines what data

[PATCH] protocol upload-pack-v2

2015-03-06 Thread Stefan Beller
From: Duy Nguyen pclo...@gmail.com Signed-off-by: Stefan Beller sbel...@google.com --- Notes: This is just aimed at untangling capabilities and refs advertisement, no new features. Hence this is missing the proposal from Duy to save one RTT. I have the impression that most

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Duy Nguyen
On Sat, Mar 7, 2015 at 11:28 AM, Stefan Beller sbel...@google.com wrote: + + advertised-refs = (no-refs / list-of-refs) + *shallow + flush-pkt I am not sure if defining shallow as part of refs advertisement is a good idea. The latter lives in the

Re: [PATCH] protocol upload-pack-v2

2015-03-06 Thread Stefan Beller
On Fri, Mar 6, 2015 at 4:28 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport Noise? @@ -124,9 +130,56 @@ has, the first