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

[Glen Choo <chooglen@google.com>]

On Thu, Aug 26, 2021 at 03:24:39PM -0700, Jonathan Tan wrote:
> > If they have to know about the object store, have you considered
> > passing the repository pointer
> > in xxx_ref_store_create() ? Then there is no possibliity to mismatch
> > the repository pointers and with the ref store.
> 
> I thought about that, but didn't want to make things worse - the effort
> in this patch set is, after all, to attempt to increase the dissociation
> between the ref stores and a certain object store (that is,
> the_repository's object store), and I thought that reintroducing an
> association (albeit to arbitrary object stores instead of a hardcoded
> object store) would be a step back.
> 
> But this may be the way to go - the ref stores already have a gitdir
> field that we could replace with a struct repository field.

I'm curious about how we'd want to resolve the general problem of ref
stores referencing odbs. 

A discussion I had with Jonathan Nieder suggests that ref stores are
doing two slightly related, but not equivalent things:

- a logical ref database that preserves its own consistency
- a layer of ref storage in such a ref database

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 answer to whether or not a ref store should refer to a certain
object store seems unresolved because a ref store is trying to do two
separate things. Perhaps it is reasonable to associate a ref database
with an object store (so that it can validate its refs), but we would
prefer to dissociate the physical ref storage layer from the object
store. (I'm paraphrasing Johnathan Nieder here, this isn't an original
thought).

Perhaps this is a question we want to resolve when considering reftable
and other ref databases.