On Sun, Feb 23, 2014 at 09:44:14AM +0700, Duy Nguyen wrote:
> (Digging up an old thread about initial refs listing in git protocol)
And now I am responding to it slowly. :)
> > 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.
Right, I recall the general feeling being that such a system would work,
and the transition would be managed by a config variable like
"remote.*.useUploadPack2". Probably with settings like:
true:
always try, but allow fall back to upload-pack
false:
never try, always use upload-pack
auto:
try, but if we fail, set remote.*.uploadPackTimestamp, and do not
try again for N days
The default would start at false, and people who know their server is
very up-to-date can turn it on. And then when many server
implementations support it, flip the default to auto. And either leave
it there forever, or eventually just set it to "true" and drop "auto"
entirely as a code cleanup.
In theory we could do more radical protocol changes here, but I think
most people are just interested in adding an opportunity for the client
to speak before the ref advertisement in order to set a few
flags/variables. That should be relatively simple, and for http we can
probably pass those flags via url parameters without any extra
compatibility/round-trip at all.
I think the main flag of interest is giving an fnmatch pattern to limit
the advertised refs. There could potentially be others, but I do not
know of any offhand.
-Peff
--
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
