Re: [RFC PATCH 1/2] refs: make _advance() check struct repo, not flag

Jonathan Tan [off-list ref] writes:

quoted

On Wed, Sep 15, 2021 at 12:41 AM Glen Choo [off-list ref] wrote:

quoted

In the current state of affairs, the files ref store and the packed ref
store seem to behave as a single logical ref database. An example of
this (that I care about in particular) is in refs/files-backend.c where
the files backend validates oids using the_repository's odb.
refs/packed-backend.c doesn't do any such validation, and presumably
just relies on the correctness of refs/files-backend.c. I assume that
this also explains why some functions in refs_be_packed are stubs.

The loose/packed storage is implemented in terms of files backend (the
public entry point) that defers to a packed backend in some cases. The
latter is implemented as a ref backend, but for no good reason.

Yes, the packed backend doesn't need to be a ref backend.

Sorry, I do not follow.  Do you mean we cannot have a version of Git
that offers say a read-only access to the repository without any
loose refs, with the default ref backend being the packed one?

Or do you mean that we can ignore such a hypothetical use case and
could reimplement the files backend that can also understand the
$GIT_DIR/packed-refs file directly without "deferring to another ref
backend which is 'packed'"?

quoted

Yes, the packed backend doesn't need to be a ref backend.

Sorry, I do not follow.  Do you mean we cannot have a version of Git
that offers say a read-only access to the repository without any
loose refs, with the default ref backend being the packed one?

Or do you mean that we can ignore such a hypothetical use case and
could reimplement the files backend that can also understand the
$GIT_DIR/packed-refs file directly without "deferring to another ref
backend which is 'packed'"?

I meant the latter - more specifically, the files backend could defer to
functions that are not necessarily inside a struct ref_storage_be.