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
> >
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
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,
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;
> +
> + /*
> + *
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
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
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
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
>
> 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
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
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
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
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
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
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.
15 matches
Mail list logo