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

Re: [PATCH 0/2] bookmarks

From
Junio C Hamano <junkio@cox.net>
Date
Apr 26, 2007, 05:53 UTC
Message-ID
<7vmz0vu1fc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.64.0704252332170.18446@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
Show 6 quoted lines
> While I like the idea of private tags, I find the idea of them having 
> their own namespace to be much more attractive than simply having the 
> ability to not export lightweight tags.
>
> In particular it means that you can control which tags are exported 
> individually.

I do not think this is limited to tags. Sometimes you may want to make some branches private. It probably is also a good idea to hide StGIT patch base refs that live under $GIT_DIR/refs/.

Here, I do not use the word "private" in the sense of being "secret", as most likely branches that share common root would have many trees and blobs in common, but in the sense of "less clutter".

How would one find out about remote refs? By running ls-remote. And that happens to also be how git-fetch follows tags (the original issue Andy had).

Over native git protocol, upload-pack is the program that runs in the repote repository and gives list of available refs and object names they point at (upload-pack.c::send_ref()). To dumb clients, update-server-info creates the equivalent information in $GIT_DIR/info/refs and that is what the ls-remote sees.

So I suspect that a more general solution would be to to teach these two programs to take notice of a new configuration variable you can set in the repository to limit the set of refs to give out. Then you do not have to introduce a new namespace,

Probably the configuration would be a glob pattern (for pathname like things, we tend to use shell glob, not regexp) to include/exclude. E.g.

	refs.expose = refs/heads/*
        refs.expose = refs/tags/*
        refs.expose = !refs/heads/*/*
        refs.expose = !refs/tags/v[0-9]*

would let you say "I would want to expose all of refs/heads/ (i.e. branches) and refs/tags (i.e. tags), but I do not want to show branches with '/' in their names, nor tags whose names do not begin with v[0-9]".

Previous: Jeffrey C. OllieNext: Julian Phillips
Message 14 of 24 in “git-fetch and unannotated tags”
  1. Andy ParkinsApr 25, 2007
  2. Julian PhillipsApr 25, 2007
  3. Andy ParkinsApr 25, 2007
  4. Junio C HamanoApr 25, 2007
  5. Andy ParkinsApr 26, 2007
  6. Andreas EricssonApr 26, 2007
  7. Jakub NarebskiApr 27, 2007
  8. Junio C HamanoApr 29, 2007
  9. 0/2 bookmarks (was: Re: git-fetch and unannotated tags)Julian Phillips, Apr 25, 2007
  10. 1/2 refs.c: change do_one_ref to not discard any of baseJulian Phillips, Apr 25, 2007
  11. 2/2 Add basic support for bookmarks (create/edit/delete/list)Julian Phillips, Apr 25, 2007
  12. A Large Angry SCMApr 26, 2007
  13. Jeffrey C. OllieApr 26, 2007
  14. Junio C HamanoApr 26, 2007
  15. Julian PhillipsApr 26, 2007
  16. Junio C HamanoApr 26, 2007
  17. Julian PhillipsApr 26, 2007
  18. Andy ParkinsApr 26, 2007
  19. Andy ParkinsApr 26, 2007
  20. Petr BaudisApr 26, 2007
  21. Andy ParkinsApr 26, 2007
  22. Julian PhillipsApr 26, 2007
  23. Karl HasselströmApr 26, 2007
  24. Linus TorvaldsApr 26, 2007

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.