Re: [RFC] protocol version 2

2017-11-10 Thread Jonathan Tan
On Fri, 20 Oct 2017 10:18:39 -0700 Brandon Williams wrote: > Some of the pain points with the current protocol spec are: After some in-office discussion, I think that the most important pain point is that we have to implement each protocol twice: once for HTTP(S), and once

Re: [RFC] protocol version 2

2017-10-31 Thread Brandon Williams
On 10/28, Philip Oakley wrote: > From: "Brandon Williams" > Sent: Friday, October 20, 2017 6:18 PM > >Objective > >=== > > > >Replace Git's current wire protocol with a simpler, less wasteful > >protocol that can evolve over time. > > > > > > >Capability

Re: [RFC] protocol version 2

2017-10-28 Thread Philip Oakley
From: "Brandon Williams" Sent: Friday, October 20, 2017 6:18 PM Objective === Replace Git's current wire protocol with a simpler, less wasteful protocol that can evolve over time. Capability Advertisement -- A server which decides to

Re: [RFC] protocol version 2

2017-10-25 Thread Junio C Hamano
Brandon Williams writes: > On 10/24, Junio C Hamano wrote: >> Brandon Williams writes: >> >> > : When specified, only references matching the given patterns >> > are displayed. >> >> I do not think you meant here. >> >> The side that is

Re: [RFC] protocol version 2

2017-10-25 Thread Brandon Williams
On 10/25, Derrick Stolee wrote: > On 10/20/2017 1:18 PM, Brandon Williams wrote: > > Overview > >== > > > >This document presents a specification for a version 2 of Git's wire > >protocol. Protocol v2 will improve upon v1 in the following ways: > > > > * Instead of multiple service

Re: [RFC] protocol version 2

2017-10-25 Thread Derrick Stolee
On 10/20/2017 1:18 PM, Brandon Williams wrote: Overview == This document presents a specification for a version 2 of Git's wire protocol. Protocol v2 will improve upon v1 in the following ways: * Instead of multiple service names, multiple commands will be supported by a

Re: [RFC] protocol version 2

2017-10-24 Thread Junio C Hamano
Brandon Williams writes: >> I actually have a reasonable guess why you want to have a separate >> delimiter (which has nothing to do with "optional delim can be >> omitted"), but I want to see it explained in this document clearly >> by its designer(s). > > Jonathan Tan

Re: [RFC] protocol version 2

2017-10-24 Thread Brandon Williams
On 10/24, Junio C Hamano wrote: > Brandon Williams writes: > > > * Capabilities were implemented as a hack and are hidden behind a NUL > > byte after the first ref sent from the server during the ref > > advertisement: > > ... > > > > * Various other technical debt

Re: [RFC] protocol version 2

2017-10-24 Thread Junio C Hamano
Brandon Williams writes: > * Capabilities were implemented as a hack and are hidden behind a NUL > byte after the first ref sent from the server during the ref > advertisement: > ... > > * Various other technical debt (e.g. abusing capabilities to > communicate

[RFC] protocol version 2

2017-10-20 Thread Brandon Williams
Objective === Replace Git's current wire protocol with a simpler, less wasteful protocol that can evolve over time. Background Git's wire protocol is the language used to clone/fetch/push from/to a remote git repository. A detailed explanation of the current protocol