Re: [PATCH v2 5/7] builtin/init: introduce handling of object storage format

[Patrick Steinhardt <ps@pks.im>]

On Wed, Oct 21, 2026 at 10:23:17AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/setup.c b/setup.c
> > index 98140a7641..3d74f8eeed 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -2466,7 +2466,8 @@ void initialize_repository_version(struct repository *repo,
> >  	 */
> >  	if (hash_algo != GIT_HASH_SHA1_LEGACY ||
> >  	    ref_storage_format != REF_STORAGE_FORMAT_FILES ||
> > -	    repo->ref_storage_payload)
> > +	    repo->ref_storage_payload ||
> > +	    strcmp(repo->object_storage_format, "files"))
> >  		target_version = GIT_REPO_VERSION_READ;
> >
> 
> Okay so this is what also sets the 'core.repositoryformatversion'
> config. I was specifically looking for that.
> 
> Does this mean that even for the files odb with a payload we need v1 of
> 'core.repositoryformatversion'?

Yes. Repository extensions aren't read in the case where we have a v0
repository, so we cannot make use of any non-default object storage
format there.

> > @@ -2490,6 +2491,12 @@ void initialize_repository_version(struct repository *repo,
> >  		repo_config_set_gently(repo, "extensions.refstorage", NULL);
> >  	}
> >
> > +	if (strcmp(repo->object_storage_format, "files"))
> > +		repo_config_set(repo, "extensions.objectstorage",
> > +				repo->object_storage_format);
> > +	else if (reinit)
> > +		repo_config_set_gently(repo, "extensions.objectstorage", NULL);
> > +
> 
> So this handled reinitializing the same repo. If there was a previously
> set object storage format, we unset it gently.
> 
> But, we already catch and error out if the extension before and after
> reinit differ, so this `else` block is not needed, no? Removing it
> passes all the tests in this patch.

This is a slightly different case: if you have a repository that uses
the default storage format, but that explicitly configures the "files"
format, then we downgrade the repository format version to 0 and unset
the extension again. This logic basically matches what we do with the
ref backend, too.

I noticed there's no test for this though. And that then led me down the
rabbit hole, because I'm not particularly happy with some of the logic
here. For example, I was doing normalization of "files" vs "files://"
somewhat inconsistently.

So I've redone some of the infrastructure here to be much closer to what
we do with the ref backend. Currently we track the object storage format
as a single URI that we pass around, whereas for the ref storage format
we pass around a backend type and payload. And that makes normalization
a lot easier, and we don't have to re-parse the URI in a lot of places.

So I've adapted the series now to use the same approach. It also makes
stuff easier to reason about, as we basically have the exact same logic
for both storage types in most places.

I'll send that later today.

Patrick