On 08/25, Jeff King wrote: > On Fri, Aug 25, 2017 at 10:35:50AM -0700, Jonathan Nieder wrote: > > > > 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'm not that worried about validating the ideas here to shoe-horn a > version field. I'm worried about what "step 2" is going to look like, > and whether "we shoe-horned a version field" can be extended to "we > shoe-horned arbitrary data". I know that this initial RFC didn't mention adding arbitrary data in the initial request but I fully intend that the final version will allow such a thing. One such idea (via the envvar, though the same can be done with git-daemon) would be to have GIT_PROTOCOL hold colon delimited values, versions could be indicated by "v1", "v2", etc while arbitrary key/values as "key=value" such that the envvar would look like: 'v1:v2:key1=value1:key2=value2'. This would mean that the client understands protocol version 1 and 2 (so either are acceptable for the server to select since there is a change the server doesn't understand v2 or some other higher version number) and that if supported it wants key1 to have value 'value1' and key2 to have value 'value2'. As you said the initial request to git-daemon is limited in length (I think envvars have a length limit too?) so we would still be limited in how much data we can send in that initial request and so we should design a new protocol in such a way that doesn't hinge on adding extra data in that first request (aside from a version number) but that can use it to speed things up if at all possible. > > Can we do that by making it a patch / letting it cook for a while in > > 'next'? :) > > If people actually ran 'next', that would help. I was hoping that we > could get it out to the masses behind a feature flag, and dangle it in > front of them with "this will improve fetch performance if you turn it > on". But that carrot implies going all the way through the follow-on > steps of designing the performance-improving v2 extensions and getting > them implemented on the server side. We run 'next' here so we will be able to get at least a little bit of feedback from a small subset of users. -- Brandon Williams
