Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> On Wed, Sep 15, 2021 at 12:41 AM Glen Choo <chooglen@xxxxxxxxxx> wrote: >> > 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'"?
