Re: [RFC 0/7] transitioning to protocol v2

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 25, 2017, 17:35 UTC
Message-ID: <20170825173550.GJ13924@aiede.mtv.corp.google.com>
In-Reply-To: <20170825172901.kvquxafudhelxqq3@sigill.intra.peff.net>

Hi,

Jeff King wrote:

> On Thu, Aug 24, 2017 at 03:53:21PM -0700, Brandon Williams wrote:

Show 12 quoted lines

>> Another version of Git's wire protocol is a topic that has been discussed and
>> attempted by many in the community over the years.  The biggest challenge, as
>> far as I understand, has been coming up with a transition plan to using the new
>> server without breaking existing clients and servers.  As such this RFC is
>> really only concerned with solidifying a transition plan.  Once it has been
>> decided how we can transition to a new protocol we can get into decided what
>> this new protocol would look like (though it would obviously eliminate the ref
>> advertisement ;).
>
> Sadly, while splitting these things apart makes the protocol
> conceptually cleaner, I'm not sure if we can consider them separately
> and avoid adding an extra round-trip to the protocol.

How about the idea of using this mechanism to implement a protocol "v1"?

The reply would be the same as today, except that it has a "protocol v1" pkt-line at the beginning. So this doesn't change the number of round-trips --- it just validates the protocol migration approach.

I agree with you that an actual protocol v2 needs to change how the capability exchange etc work. bmwill@ has mentioned some thoughts about this privately. Probably he can say more here too.

[...]

> Given the techniques you've used here, I suspect the answer may be
> "yes". We could stick arbitrary data in each of those methods (though I
> suspect our length may be limited to about 1024 bytes if we want
> compatibility with very old git servers).

Yes, including arbitrary data to be able to include some kinds of requests inline in the initial request is one of the design goals.

Show 11 quoted lines

>> The biggest question I'm trying to answer is if these are reasonable ways with
>> which to communicate a request to a server to use a newer protocol, without
>> breaking current servers/clients.  As far as I've tested, with patches 1-5
>> applied I can still communicate with current servers without causing any
>> problems.
>
> Current git.git servers, I assume?. How much do we want to care about
> alternate implementations? I would not be surprised if other git://
> implementations are more picky about cruft after the virtual-host field
> (though I double-checked GitHub's implementation at least, and it is
> fine).

FWIW JGit copes fine with this.

> I don't think libgit2 implements the server side. That leaves probably
> JGit, Microsoft's VSTS (which I think is custom), and whatever Atlassian
> and GitLab use.

I'd be happy if someone tests the patches against those. :)

> There's not really a spec here.

Technically pack-protocol is a spec, just not a very clear one.

It does say this kind of client request is invalid. The idea of this series is to change the spec. :)

[...]

> I dunno. Maybe it would be enough to have a config to switch off this
> feature, which would give people using those systems an escape hatch
> (until they upgrade).

I'd rather not. That means there's less motivation for people to report compatibility problems so we can fix them.

It might be necessary as a temporary escape hatch, though.

>                        Or alternatively, I guess make this optional to
> start with, and let early adopters turn it on and complain to their server
> vendors for a while before flipping the default to on.

Can we do that by making it a patch / letting it cook for a while in 'next'? :)

Thanks, Jonathan