Re: [PATCH 0/2] Hiding some refs in ls-remote

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2013, 18:19 UTC
Message-ID: <7vip6rn2ea.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 15 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> Should the client side learn how to list hidden refs too? I'm thinking
>> of an extreme case where upload-pack advertises nothing (or maybe just
>> refs/heads/master) and it's up to the client to ask for the ref
>> selection it's interested in. upload-pack may need more updates to do
>> that, I think.
>
> What you are talking about is a different goal.
>
> Look at this as a mechanism for the repository owner to control the
> clutter in what is shown to the intended audience of what s/he
> publishes in the repository.  Network bandwidth reduction of
> advertisement is a side effect of clutter reduction, and not
> necessarily the primary goal.

As a separate and follow-up topic, I can see a future where we also have .delayref (in addition to .hideref) configuration, that causes the upload-pack to:

 * omit refs that are marked as "delayed";

 * advertise "allow-expand-ref=<value>" where the value is the
   pattern used to specify which refs are omitted via this mechanism
   (e.g. "refs/*" in your extreme example, or perhaps "refs/tags/"
   if you only advertise branches in order to limit the bandwidth);

and then a fetch-pack that is interested in fetching "refs/foo/bar", after seeing that it matches one of the "allow-expand-ref" patterns, to ask "expand-ref refs/foo/bar", expect the upload-pack to respond with "refs/foo/bar <value of that ref>" (or "refs/foo/bar does not exist"), before going into the usual "want" exchange ("ls-remote" would of course do the same, and pattern-less "ls-remote" may even ask to expand everything by saying "expand-ref refs/*" (where the capability said "allow-expand-ref=refs/*" in your extreme example) to grab everything discoverable).

That is _primarily_ for trading network bandwidth with initial latency; as far as the end-result is concerned, delayed ones to be expanded on demand are just as discoverable as the ones advertised initially.

I think we'd want to have both in the end. It just happens I just posted the beginning of clutter-reduction one, as I think developing both in parallel would be messy and hideref is probably less involved than the delayref.