On Thu, Feb 7, 2013 at 1:16 AM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Feb 06, 2013 at 04:12:10PM -0800, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >> > I think there's a simpler way to do this, which is that: >> > >> > * New clients supporting v2 of the protocol send some piece of data >> > that would break old servers. >> > >> > * If that fails the new client goes "oh jeeze, I guess it's an old >> > server", and try again with the old protocol. >> > >> > * The client then saves a date (or the version the server gave us) >> > indicating that it tried the new protocol on that remote, tries >> > again sometime later. >> >> For that to work, the new server needs to wait for the client to >> speak first. How would that server handle old clients who expect to >> be spoken first? Wait with a read timeout (no timeout is the right >> timeout for everybody)? > > If the new client can handle the old-style server's response, then the > server can start blasting out refs (optionally after a timeout) and stop > when the client interrupts with "hey, wait, I can speak the new > protocol". The server just has to include "you can interrupt me" in its > capability advertisement (obviously it would have to send out at least > the first ref with the capabilities before the timeout). Can't this also be handled by passing an extra argument to upload-pack? Whether you're talking http, ssh + normal shell, ssh + git-shell or git:// you pass some argument that older clients would reject on but would cause newer clients that know about that argument to wait for you to speak before blasting refs at you. It would mean that older clients (e.g. older git-shell) would reject your initial connection, but you could just try again, and save away info about that remote's version. -- 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