Re: [PATCH v3 12/35] serve: introduce git-serve

On Tue, Mar 06, 2018 at 07:29:02AM +0100, Jeff King wrote: > > We want to do better (e.g. see [1]) but that's a bigger change than > > the initial protocol v2. > > > > As Brandon explained it to me, we really do want to use stateless-rpc > > semantics by default, since that's just better for

Re: [PATCH v3 12/35] serve: introduce git-serve

On Mon, Mar 05, 2018 at 01:36:49PM -0800, Jonathan Nieder wrote: > > I agree that would be a lot more pleasant for adding protocol features. > > But I just worry that the stateful protocols get a lot less efficient. > > I'm having trouble coming up with an easy reproduction, but my > >

Re: [PATCH v3 12/35] serve: introduce git-serve

Hi, Jeff King wrote: > I agree that would be a lot more pleasant for adding protocol features. > But I just worry that the stateful protocols get a lot less efficient. > I'm having trouble coming up with an easy reproduction, but my > recollection is that http has some nasty corner cases,

Re: [PATCH v3 12/35] serve: introduce git-serve

On Mon, Mar 05, 2018 at 10:43:21AM -0800, Brandon Williams wrote: > In the current protocol http has a lot of additional stuff that's had to > be done to it to get it to work with a protocol that was designed to be > stateful first. What I want is for the protocol to be designed > stateless

Re: [PATCH v3 12/35] serve: introduce git-serve

On 03/02, Jeff King wrote: > On Fri, Feb 23, 2018 at 01:45:57PM -0800, Brandon Williams wrote: > > > I think this is the price of extending the protocol in a backward > > compatible way. If we don't want to be backwards compatible (allowing > > for graceful fallback to v1) then we could design

Re: [PATCH v3 12/35] serve: introduce git-serve

On Fri, Feb 23, 2018 at 01:45:57PM -0800, Brandon Williams wrote: > I think this is the price of extending the protocol in a backward > compatible way. If we don't want to be backwards compatible (allowing > for graceful fallback to v1) then we could design this differently. > Even so we're not

Re: [PATCH v3 12/35] serve: introduce git-serve

On 02/27, Jonathan Tan wrote: > On Fri, 23 Feb 2018 13:33:15 -0800 > Brandon Williams wrote: > > > On 02/21, Jonathan Tan wrote: > > > As someone who is implementing the server side of protocol V2 in JGit, I > > > now have a bit more insight into this :-) > > > > > > First of

Re: [PATCH v3 12/35] serve: introduce git-serve

On Fri, 23 Feb 2018 13:33:15 -0800 Brandon Williams wrote: > On 02/21, Jonathan Tan wrote: > > As someone who is implementing the server side of protocol V2 in JGit, I > > now have a bit more insight into this :-) > > > > First of all, I used to not have a strong opinion on

Re: [PATCH v3 12/35] serve: introduce git-serve

On 02/22, Jeff King wrote: > On Tue, Feb 06, 2018 at 05:12:49PM -0800, Brandon Williams wrote: > > > +In protocol v2 communication is command oriented. When first contacting a > > +server a list of capabilities will advertised. Some of these capabilities > > +will be commands which a client can

Re: [PATCH v3 12/35] serve: introduce git-serve

On 02/21, Jonathan Tan wrote: > On Tue, 6 Feb 2018 17:12:49 -0800 > Brandon Williams wrote: > > > .gitignore | 1 + > > Documentation/technical/protocol-v2.txt | 114 +++ > > Makefile| 2 + > >

Re: [PATCH v3 12/35] serve: introduce git-serve

On Tue, Feb 06, 2018 at 05:12:49PM -0800, Brandon Williams wrote: > +In protocol v2 communication is command oriented. When first contacting a > +server a list of capabilities will advertised. Some of these capabilities > +will be commands which a client can request be executed. Once a command

Re: [PATCH v3 12/35] serve: introduce git-serve

On Tue, 6 Feb 2018 17:12:49 -0800 Brandon Williams wrote: > .gitignore | 1 + > Documentation/technical/protocol-v2.txt | 114 +++ > Makefile| 2 + > builtin.h | 1 +

[PATCH v3 12/35] serve: introduce git-serve

Introduce git-serve, the base server for protocol version 2. Protocol version 2 is intended to be a replacement for Git's current wire protocol. The intention is that it will be a simpler, less wasteful protocol which can evolve over time. Protocol version 2 improves upon version 1 by