On Wed, Oct 3, 2012 at 11:55 AM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote: >> Jeff King <peff@xxxxxxxx> writes: >> >> >> Has there been any work on extending the protocol so that the client >> >> tells the server what refs it's interested in? >> > >> > I don't think so. It would be hard to do in a backwards-compatible way, >> > because the advertisement is the first thing the server says, before it >> > has negotiated any capabilities with the client at all. >> >> That is being discussed but hasn't surfaced on the list. > > Out of curiosity, how are you thinking about triggering such a new > behavior in a backwards-compatible way? Invoke git-upload-pack2, and > fall back to reconnecting to start git-upload-pack if it fails? Basically, yes. New clients connect for git-upload-pack2. Over git:// the remote peer will just close the TCP socket with no messages. The client can fallback to git-upload-pack and try again. Over SSH a similar thing will happen in the sense there is no data output from the remote side, so the client can try again. This has the downside of authentication twice over SSH, which may prompt for a password twice. But the user can get out of this by setting remote.NAME.uploadpack = git-upload-pack and thus force the Git client to use the current protocol if they have a new client and must continue to work over SSH with an old server, and don't use an ssh-agent. Over HTTP we can request ?service=git-upload-pack2 and retry just like git:// would, or be a bit smarter and say ?service=git-upload-pack&v=2, and determine the protocol support of the remote peer based on the response we get. If we see an immediate advertisement its still the "v1" protocol, if we get back the "yes I speak v2" response like git:// would see, we can continue the conversation from there. -- 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