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
