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

Message

Karthik Nayak Dec. 21, 2023, 5:07 p.m. UTC

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(-)