(Digging up an old thread about initial refs listing in git protocol) On Thu, Feb 7, 2013 at 7:12 AM, Junio C Hamano <gits...@pobox.com> wrote: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> 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)?
I think the client always speaks first when it asks for a remote service. Earlier in this thread you described the new protocol upload-pack-2. Why can't it be a new service "upload-pack-2" in git-daemon? So new client will try requesting "upload-pack-2" service with client capability advertisement before ref listing. Old servers do not recognize this service and disconnect so the new client falls back to the good old "upload-pack" (one more round trip though, but you could configure new client to use old protocol for certain "old" hosts). Similar thing happens for ssh transport. "upload-pack" service is always there for old clients. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
