Re: [PATCH v5 10/11] refs/reftable: lazy-load configuration to fix chicken-and-egg

[Patrick Steinhardt <ps@pks.im>]

On Wed, Jun 24, 2026 at 05:18:21PM -0500, Justin Tobler wrote:
> On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> > diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> > index 608d71cf10..d74131a5ae 100644
> > --- a/refs/reftable-backend.c
> > +++ b/refs/reftable-backend.c
> > @@ -141,10 +141,21 @@ struct reftable_ref_store {
> >  	 */
> >  	struct strmap worktree_backends;
> >  	struct reftable_stack_options stack_options;
> > -	struct reftable_write_options write_options;
> > +
> > +	/*
> > +	 * Options used when writing to or compacting the reftable stacks.
> > +	 * These are parsed from the configuration lazily on first use via
> > +	 * `reftable_be_write_options()` so that we don't have to access the
> > +	 * configuration when initializing the ref store. Do not access these
> > +	 * fields directly, but use the accessor instead.
> > +	 */
> > +	struct reftable_be_write_options {
> > +		struct reftable_write_options opts;
> > +		enum log_refs_config log_all_ref_updates;
> 
> Any reason in particular that `log_all_ref_updates` is the only option
> outside of `struct reftlable_write_options` here? Isn't it also only
> used during writes?

`log_all_ref_updates` is part of the backend's logic, whereas the
`struct reftable_write_options` is part of the reftable library's logic.
So they have different scopes, and the former cannot be handled in the
library.

Patrick