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

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> 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 (after reporting the bug, of
>    course!) blacklist certain protocol versions to work around server
>    bugs.  But this should not affect my behavior as a server --- in
>    my role as a server, these server-side bugs have no effect on me.
>
>  - As a server operator, I may want to (after reporting the bug, of
>    course!) blacklist certain protocol versions to work around client
>    bugs.  But this should not affect my behavior as a client --- in my
>    role as a client, these client-side bugs have no effect on me.

Good point.  

> Making the client-side case configurable seems important since Git is
> widely used in environments where it may not be easy to control the
> deployed version (so having configuration as an escape hatch is
> important).
>
> Making the server-side case configurable seems less important since
> Git server operators usually have tight control over the deployed Git
> version and can apply a targetted fix or workaround.

The above also suggests that the configuration variable that lets
you specify the protocol version should hint in its name which
direction of the protocol it controls.  Even if we decide that we'd
add only the variable for the initiator side for now, if it is
possible that we later may want to add another for the acceptor
side, we need to do it right from day one.

Perhaps protocol.connectVersion(s) vs protocol.acceptVersion(s) or
something like that?