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 for SSH (and friends)

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 Advertisement > >---

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 communicate (based on

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 listing what it has has no reason to kno

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 name

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 sing

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 suggested that we tighten

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 (e.g. abusing capab

Re: [RFC] protocol version 2

2017-10-23 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 agent and symref da

[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 spec