On 09/18, Stefan Beller wrote: > >> From a users POV this may be frustrating as I would imagine that > >> people want to run > >> > >> git config --global protocol.version 2 > >> > >> to try it out and then realize that some of their hosts do not speak > >> 2, so they have to actually configure it per repo/remote. > > > > The point would be to be able to set this globally, not per-repo. Even > > if a repo doesn't speak v2 then it should be able to gracefully degrade > > to v1 without the user having to do anything. The reason why there is > > this escape hatch is if doing the protocol negotiation out of band > > causing issues with communicating with a server that it can be shut off. > > In the current situation it is easy to assume that if v1 (and not v0) > is configured, that the users intent is "to try out v1 and fallback > gracefully to v0". > > But this will change over time in the future! > > Eventually people will have the desire to say: > "Use version N+1, but never version N", because N has > performance or security issues; the user might not want > to bother to try N or even actively want to be affirmed that > Git will never use version N. > > In this future we need a mechanism, that either contains a > white list or black list of protocols. To keep it simple (I assume > there won't be many protocol versions), a single white list will do. > > However transitioning from the currently proposed "try the new > configured thing and fallback to whatever" to "this is the exact list > of options that Git will try for you" will be hard, as we may break people > if we do not unconditionally fall back to v0. > > That is why I propose to start with an explicit white list as then we > do not have to have a transition plan or otherwise work around the > issue. Also it doesn't hurt now to use > > git config --global protocol.version v1,v0 > > instead compared to the proposed configuration above. > (Even better yet, then people could play around with "v1 only" > and see how it falls apart on old servers)
Except we can't start with an explicit whitelist because we must fallback to v0 if v1 isn't supported otherwise we would break people. That is unless we have the semantics of: If not configured v0 will be used, otherwise only use the configured protocol versions. -- Brandon Williams
