On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote: > > 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. It's a shame that we have to reestablish the TCP or ssh connection to do the retry. The password thing is annoying, but also it just wastes a round-trip. It means we'd probably want to default the v2 probe to off (and let the user turn it on for a specific remote) until v2 is much more common than v1. Otherwise everyone pays the price. It may also be worth designing v2 to handle more graceful capability negotiation so this doesn't come up again. Another alternative would be to tweak git-daemon to allow more graceful fallback. That wouldn't help us now, but it would if we ever wanted a v3. For stock ssh, you could send: sh -c 'git upload-pack2; test $? = 127 && git-upload-pack' which would work if you have an unrestricted shell on the other side. But it would break for a restricted shell or other "fake" ssh environment. It's probably too ugly to have restricted shells recognize that as a magic token (well, I could maybe even live with the ugliness, but it is not strictly backwards compatible). I was hoping we could do something like "git upload-pack --v2", but I'm pretty sure current git-daemon would reject that. > 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. Yeah, I would think "&v=2" would be better simply to avoid the round-trip if we fail. It should be safe to turn the new protocol on by default for http, then. -Peff -- 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