From: Junio C Hamano Date: Tue, 05 Feb 2013 17:38:52 GMT Subject: Re: [PATCH v3 0/8] Hiding refs Message-ID: <7vy5f2slsj.fsf@alter.siamese.dyndns.org> In-Reply-To: <5110DF1D.8010505@alum.mit.edu> Michael Haggerty writes: > On 02/05/2013 09:33 AM, Jonathan Nieder wrote: >> Michael Haggerty wrote: >> >>> I would again like to express my discomfort about this feature, which is >>> already listed as "will merge to next". Frankly, I have the feeling >>> that this feature is being steamrolled in before a community consensus >>> has been reached and indeed before many valid points raised by other >>> members of the community have even been addressed. For example: >> >> In $dayjob I work with Gerrit, so I think I can start to answer some >> of these questions. >> >>> * I didn't see a response to Peff's convincing arguments that this >>> should be a client-side feature rather than a server-side feature [1]. >> >> The client can't control the size of the ref advertisement. That is >> the main motivation if I understood correctly. > > Not according to Junio [4]: > > 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. See my response to Jonathan. > Hiderefs creates a "dark" corner of a remote git repo that can hold > arbitrary content that is impossible for anybody to discover but > nevertheless possible for anybody to download (if they know the name of > a hidden reference). That is why allow-tip-sha1-in-want is a separate opt-in feature only the server side controls.