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

[RFC 0/2] Initial changes to support printing all refs

From
Karthik Nayak <karthik.188@gmail.com>
Date
Dec 21, 2023, 17:07 UTC
Message-ID
<20231221170715.110565-1-karthik.188@gmail.com>

With the upcoming introduction of the reftable backend, it becomes ever so important to provide the necessary tooling for printing all refs associated with a repository.

While regular refs stored within the "refs/" namespace are currently supported by multiple commands like git-for-each-ref(1), git-show-ref(1). Neither support printing all the operational refs within the repository.

This is crucial because with the reftable backend, all these refs will also move to reftable. It would be necessary to identify all the refs that are stored within the reftable since there is no easy way to do so otherwise. This is because the reftable itself is a binary format and all access will be via git. Unlike the filesystem backend, which allows access directly via the filesystem.

This patch series is an RFC to discuss the intent and direction to be taken to implement tooling for printing all refs in a repository. The patches in this series implement a rather simple way to do this, by iterating over a static list of operational refs. The drawback of this approach is that this could still miss refs in the reftable/files backend which are not in "refs" namespace or part of the list. The positive being that this is ref backend agnostic.

The alternate approach would be to patch this inside individual backends respectively, in the reftable backend this is rather simple, since we simply iterate over all refs and not filter for "refs" namespace. In the files backend, this can be done in two ways:

1. static approach: similar to this patch series, the files backend
would iterate over a static list of operational refs apart from the
"refs" directory.
2. dynamic approach: iterate over all files in `.git` folder and print
any refs if encountered. This is rather tedious and error prone, since
any file could be mistaken for a reference if the content is reference
like.

Personally, I'm leaning towards implementing this functionality inside individual backends respectively, because that would allow the reftable backend to print all its refs while the current approach might miss some refs. But with the files backend, it would be best to still use a static list.

Over this, I'm also curious on what the mailing list thinks about exposing this to the client side. Would an `--all` option for git-for-each-ref(1) be sufficient?

Karthik Nayak (2):
  refs: introduce the `refs_single_ref` function
  ref-filter: support filtering of operational refs
 ref-filter.c | 12 ++++++++++++
 ref-filter.h |  4 +++-
 refs.c       | 26 +++++++++++++++++++++++---
 refs.h       |  5 +++++
 4 files changed, 43 insertions(+), 4 deletions(-)
-- 
2.43.GIT
Next: Karthik Nayak
Message 1 of 27 in “[RFC 0/2] Initial changes to support printing all refs”
  1. Karthik NayakDec 21, 2023
  2. 1/2 refs: introduce the `refs_single_ref` functionKarthik Nayak, Dec 21, 2023
  3. 2/2 ref-filter: support filtering of operational refsKarthik Nayak, Dec 21, 2023
  4. Junio C HamanoDec 21, 2023
  5. Karthik NayakDec 22, 2023
  6. Junio C HamanoDec 26, 2023
  7. Karthik NayakJan 2, 2024
  8. Junio C HamanoJan 2, 2024
  9. Taylor BlauJan 2, 2024
  10. Patrick SteinhardtJan 3, 2024
  11. Karthik NayakJan 3, 2024
  12. Junio C HamanoJan 3, 2024
  13. Patrick SteinhardtJan 3, 2024
  14. Junio C HamanoJan 3, 2024
  15. Patrick SteinhardtJan 3, 2024
  16. Junio C HamanoJan 3, 2024
  17. Patrick SteinhardtJan 3, 2024
  18. Junio C HamanoJan 3, 2024
  19. Patrick SteinhardtJan 3, 2024
  20. Karthik NayakJan 4, 2024
  21. Junio C HamanoJan 4, 2024
  22. Taylor BlauJan 3, 2024
  23. Patrick SteinhardtJan 3, 2024
  24. Taylor BlauJan 3, 2024
  25. Patrick SteinhardtDec 28, 2023
  26. Karthik NayakJan 2, 2024
  27. Taylor BlauJan 2, 2024

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.