Am Mittwoch, 3. Oktober 2012, 16:13:16 schrieb Jeff King: > 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. Would it be possible to use this workflow: - Every client connects per default to v1 - If server is capable of v2, it sends a flag along with the usual response (A v1 server will obviously not send that flag) - If client is also capable of v2 and gets the flag, it enables v2 for just that remote (probably unless the user said, "i never want to") - Next time the client connects to that remote it will use v2. I'm not sure, if this is possible, since I think to remember that I have read in the Documentation folder something along the line: Capabilities announced from the server mean "I want you to use exactly these flags". Sascha -- 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