Hi, Jeff King wrote: > On Thu, Aug 24, 2017 at 03:53:21PM -0700, Brandon Williams wrote: >> 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. >> 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
