Junio C Hamano wrote: > Duy Nguyen <pclo...@gmail.com> writes: >> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhag...@alum.mit.edu> >> wrote:
>>> Hiderefs creates a "dark" corner of a remote git repo [...] >> Or you can think hiderefs is the first step to addressing the >> initial ref advertisment problem. The series says hidden refs are >> to be fetched out of band, but that's not the only way. > > Let me help unconfuse this thread. > > I think the series as 8-patch series was poorly presented, and > separating it into two will help understanding what they are about. > > The first three: > > upload-pack: share more code > upload-pack: simplify request validation > upload/receive-pack: allow hiding ref hierarchies > > is _the_ topic of the series. As far as I am concerned (I am not > speaking for Gerrit users, but am speaking as the Git maintainer), > the topic is solely about uncluttering. There may be refs that the > server end may need to keep for its operation, but that remote users > have _no_ business knowing about. An obvious question when looking at that alone is, is there ever actually need for such private refs? If the refs are not meant to be shared with users *at all*, why are they even refs? An answer is "because refs force gc to keep the corresponding objects". For example, the sysadmin may want to keep refs/archived/ refs for dead branches that should not be advertised or accessible to the user any more. Seems sane, though not especially exciting. What is more exciting to me is that it is a first step toward addressing the complicated problem of offering access to more refs than can be efficiently presented in the current ref advertisement. I think that's a harder problem but something like this would be needed in order to support existing clients without performance degredation. And in the meantime, it helps with the refs/archived case. Thanks for explaining. Jonathan -- 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
