Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-13 Thread Brandon Williams
On 10/10, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > Given some of this discussion though, maybe we want to change the > > semantics of 'protocol.version' so that both servers and clients respect > > it. As of right now, these patches have the server always allow > >

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-10 Thread Junio C Hamano
Jonathan Nieder writes: > If we want to make the advertised protocol versions on the server side > configurable, I think it should be independent from the configuration > for protocol versions to use on the client side. Rationale: > > - As a client-side user, I may want to

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-10 Thread Stefan Beller
On Tue, Oct 10, 2017 at 2:17 PM, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > >> Given some of this discussion though, maybe we want to change the >> semantics of 'protocol.version' so that both servers and clients respect >> it. I have no preference for this,

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-10 Thread Jonathan Tan
On Tue, 3 Oct 2017 13:15:00 -0700 Brandon Williams wrote: > +enum protocol_version determine_protocol_version_server(void) > +{ > + const char *git_protocol = getenv(GIT_PROTOCOL_ENVIRONMENT); > + enum protocol_version version = protocol_v0; > + > + /* > + *

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-10 Thread Jonathan Nieder
Hi, Brandon Williams wrote: > Given some of this discussion though, maybe we want to change the > semantics of 'protocol.version' so that both servers and clients respect > it. As of right now, these patches have the server always allow > protocol v0 and v1? Though that doesn't do much right

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-10 Thread Brandon Williams
On 10/06, Martin Ågren wrote: > On 6 October 2017 at 11:40, Junio C Hamano wrote: > > Simon Ruderich writes: > > > >> Did you consider Stefan Beller's suggestion regarding a > >> (white)list of allowed versions? > >> > >> On Mon, Sep 18, 2017 at 01:06:59PM

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-08 Thread Martin Ågren
On 6 October 2017 at 11:40, Junio C Hamano wrote: > Simon Ruderich writes: > >> Did you consider Stefan Beller's suggestion regarding a >> (white)list of allowed versions? >> >> On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote: >>> Thinking

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-08 Thread Martin Ågren
On 6 October 2017 at 22:27, Stefan Beller wrote: >> I might be naive in thinking that protocol.version could be removed or >> redefined at our discretion just because it's marked as "experimental". > > Well the redefinition might very well occur, when we now say "set to v1 >

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Stefan Beller
> I might be naive in thinking that protocol.version could be removed or > redefined at our discretion just because it's marked as "experimental". Well the redefinition might very well occur, when we now say "set to v1 to test v1 and fallback to v0 otherwise", but long term we want a white or

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Martin Ågren
On 6 October 2017 at 14:09, Junio C Hamano wrote: > Martin Ågren writes: > >> Maybe I'm missing something Git-specific, but isn't the only thing that >> needs to be done now, to document/specify that 1) the client should send >> its list ordered by

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Junio C Hamano
Martin Ågren writes: > Maybe I'm missing something Git-specific, but isn't the only thing that > needs to be done now, to document/specify that 1) the client should send > its list ordered by preference, 2) how preference is signalled, and 3) > that the server gets to

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Martin Ågren
On 6 October 2017 at 11:40, Junio C Hamano wrote: > Simon Ruderich writes: > >> Did you consider Stefan Beller's suggestion regarding a >> (white)list of allowed versions? >> >> On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote: >>> Thinking

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Junio C Hamano
Simon Ruderich writes: > Did you consider Stefan Beller's suggestion regarding a > (white)list of allowed versions? > > On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote: >> Thinking about this, how about: >> >> If not configured, we do as we want. (i.e. Git has

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-06 Thread Simon Ruderich
On Tue, Oct 03, 2017 at 01:15:00PM -0700, Brandon Williams wrote: > [snip] > > +protocol.version:: > + Experimental. If set, clients will attempt to communicate with a > + server using the specified protocol version. If unset, no > + attempt will be made by the client to communicate

[PATCH v3 03/10] protocol: introduce protocol extention mechanisms

2017-10-03 Thread Brandon Williams
Create protocol.{c,h} and provide functions which future servers and clients can use to determine which protocol to use or is being used. Also introduce the 'GIT_PROTOCOL' environment variable which will be used to communicate a colon separated list of keys with optional values to a server.