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

From: Glen Choo <chooglen@google.com>
Date: Sep 14, 2021, 22:41 UTC
Message-ID: <YUElL3RI0VTnjE5C@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <20210826222439.3915402-1-jonathantanmy@google.com>

On Thu, Aug 26, 2021 at 03:24:39PM -0700, Jonathan Tan wrote:

Show 14 quoted lines

> > 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.