git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 0/8] Hiding refs

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Feb 6, 2013, 19:45 UTC
Message-ID
<20130206194542.GB21003@google.com>
In-Reply-To
<7v4nhpckwd.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> Hiderefs creates a "dark" corner of a remote git repo
[...]
Show 20 quoted lines
>> 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

Previous: Junio C HamanoNext: Michael Haggerty
Message 23 of 54 in “Hiding refs”
  1. 0/8 Hiding refsJunio C Hamano, Jan 30, 2013
  2. 1/8 upload-pack: share more codeJunio C Hamano, Jan 30, 2013
  3. 2/8 upload-pack: simplify request validationJunio C Hamano, Jan 30, 2013
  4. 3/8 upload/receive-pack: allow hiding ref hierarchiesJunio C Hamano, Jan 30, 2013
  5. Jeff KingFeb 5, 2013
  6. Junio C HamanoFeb 5, 2013
  7. Jeff KingFeb 6, 2013
  8. Junio C HamanoFeb 6, 2013
  9. 4/8 parse_fetch_refspec(): clarify the codeflow a bitJunio C Hamano, Jan 30, 2013
  10. 5/8 fetch: use struct ref to represent refs to be fetchedJunio C Hamano, Jan 30, 2013
  11. 6/8 upload-pack: optionally allow fetching from the tips of hidden refsJunio C Hamano, Jan 30, 2013
  12. 7/8 fetch: fetch objects by their exact SHA-1 object namesJunio C Hamano, Jan 30, 2013
  13. Jeff KingFeb 5, 2013
  14. Jeff KingFeb 5, 2013
  15. Junio C HamanoFeb 5, 2013
  16. 8/8 WIP: receive.allowupdatestohiddenJunio C Hamano, Jan 30, 2013
  17. Michael HaggertyFeb 5, 2013
  18. Jonathan NiederFeb 5, 2013
  19. Michael HaggertyFeb 5, 2013
  20. Junio C HamanoFeb 5, 2013
  21. Duy NguyenFeb 6, 2013
  22. Junio C HamanoFeb 6, 2013
  23. Jonathan NiederFeb 6, 2013
  24. Michael HaggertyFeb 6, 2013
  25. Junio C HamanoFeb 6, 2013
  26. Ævar Arnfjörð BjarmasonFeb 6, 2013
  27. Junio C HamanoFeb 7, 2013
  28. Jeff KingFeb 7, 2013
  29. Ævar Arnfjörð BjarmasonFeb 7, 2013
  30. Junio C HamanoFeb 7, 2013
  31. Duy NguyenFeb 23, 2014
  32. Jeff KingMar 11, 2014
  33. Junio C HamanoMar 11, 2014
  34. Jeff KingMar 11, 2014
  35. Junio C HamanoMar 11, 2014
  36. Jeff KingMar 11, 2014
  37. Duy NguyenMar 14, 2014
  38. Shawn PearceMar 14, 2014
  39. Duy NguyenMar 14, 2014
  40. Shawn PearceMar 15, 2014
  41. Jeff KingMar 18, 2014
  42. Duy NguyenMar 18, 2014
  43. Duy NguyenMar 18, 2014
  44. Duy NguyenMar 15, 2014
  45. Jeff KingMar 18, 2014
  46. Jeff KingFeb 6, 2013
  47. Junio C HamanoFeb 5, 2013
  48. Junio C HamanoFeb 5, 2013
  49. Michael HaggertyFeb 6, 2013
  50. Jonathan NiederFeb 6, 2013
  51. Michael HaggertyFeb 6, 2013
  52. Jed BrownFeb 7, 2013
  53. Junio C HamanoFeb 9, 2013
  54. Jed BrownFeb 10, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.