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

Re: [PATCH v3 0/8] Hiding refs

From
Jeff King <peff@peff.net>
Date
Feb 6, 2013, 22:56 UTC
Message-ID
<20130206225616.GI27507@sigill.intra.peff.net>
In-Reply-To
<7v4nhpckwd.fsf@alter.siamese.dyndns.org>
On Wed, Feb 06, 2013 at 11:17:06AM -0800, Junio C Hamano wrote:
Show 24 quoted lines
> 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.  Allowing the server to keep these
> refs in the repository, while not showing these refs over the wire,
> is the problem the series solves.
> 
> In other words, it is not about "these are *usually* not wanted by
> clients, so do not show them by default".  It is about "these are
> not to be shown, ever".
> 
> OK?

Right. I am not opposed to this series, as it does have a use-case. And if it helps Gerrit folks or other users unclutter, great. The fact that I could throw away the custom receive.hiderefs patch we use at GitHub is a bonus. If people want fancier things, they can do them separately.

_But_. As a potential user of the feature (to hide refs/pull/*), I do not think it is sufficiently flexible for me to use transfer.hiderefs (or uploadpack.hiderefs). We use "fetch" internally to migrate objects between forks and our alternates repos. And in that case, we really do want to see all refs. In other words, all fetches are not the same: we would want upload-pack to understand the difference between a client fetch and an internal administrative fetch. But this feature does not provide that lee-way. Even if you tried:

  git fetch -u 'git -c uploadpack.hiderefs= upload-pack'
the list nature of the config variable means you cannot reset it.

This isn't a show-stopper for the series; it may just mean that it is not a good fit for GitHub's use case, but others (like Gerrit) may benefit. But since refs/pull is used as an example of where this could be applied, I wanted to point out that it does not achieve that goal.

-Peff
Previous: Jeff KingNext: Junio C Hamano
Message 46 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.