Re: [PATCH v3 0/8] Hiding refs

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 23, 2014, 02:44 UTC
Message-ID: <CACsJy8Aas3tRoDp9LQw7Nwf6+S3QnvwA7h7s-sHVY+1yFKhTYg@mail.gmail.com>
In-Reply-To: <7vmwvh9e3p.fsf@alter.siamese.dyndns.org>

(Digging up an old thread about initial refs listing in git protocol)

On Thu, Feb 7, 2013 at 7:12 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@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