Re: [PATCH v3 0/8] Hiding refs

From: Jeff King <peff@peff.net>
Date: Mar 11, 2014, 01:49 UTC
Message-ID: <20140311014945.GB12033@sigill.intra.peff.net>
In-Reply-To: <CACsJy8Aas3tRoDp9LQw7Nwf6+S3QnvwA7h7s-sHVY+1yFKhTYg@mail.gmail.com>

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. :)

Show 17 quoted lines

> > 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