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 main
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
> > recollectio
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, because
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 first
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 th
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 c
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 all, I used to not
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 the existence of a
>
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
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 +
> > builtin.h
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
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 +
> builtin/serve.c
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 eliminatin
13 matches
Mail list logo
