On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > It's very hard to keep backward compatibility if you want to stop the > initial ref adverstisement, costly when there are lots of refs. But we > can let both protocols run in parallel, with the old one advertise the > presence of the new one. Then the client could switch to new protocol > gradually. This way new protocol could forget about backward > compatibility. See > > http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 Yes, the whole thread is worth a read, but the approach suggested by that article $gmane/244325 is very good for its simplicity. The server end programs, upload-pack and receive-pack, need to only learn to advertise the availability of upload-pack-v2 and receive-pack-v2 services and the client side programs, fetch-pack and push-pack, need to only notice the advertisement and record the availability of v2 counterparts for the current remote *and* continue the exchange in v1 protocol. That way, there is very little risk for breaking anything. And the programs for new protocol exchange do not have to worry about having to talk with older counterparts and downgrading the protocol inline at all. As long as we learn from our past mistakes and make sure that the very initial exchange will be kept short (one of the items in the list of limitations, $gmane/264000), future servers and clients can upgrade the protocol they talk inline by probing capabilities, just like the current protocol allows them to choose extensions. The biggest issue in the current protocol is not "who speaks first" (that is merely one aspect) but "what is spoken first", iow, "one side blinly gives a large message as the first thing", which cannot be squelched by capability exchange. So if we are going to discuss a new protocol, I'd prefer to see the discussion without worrying too much about how to inter-operate with the current vintage of Git. It is no longer an interesting problem, as we know how to solve it with minimum risk. Instead, I'd like to see us design the new protocol in such a way that it is in-line upgradable without repeating our past mistakes. I am *not* convinced that we want multiple suite of protocols that must be chosen from to suit the use pattern, as mentioned somewhere upthread, by the way. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html