Re: [PATCH 04/16] odb/source-packed: start converting to a proper `struct odb_source`

[Patrick Steinhardt <ps@pks.im>]

On Tue, Jun 09, 2026 at 09:27:25AM +0200, Patrick Steinhardt wrote:
> On Mon, Jun 08, 2026 at 08:29:04AM -0700, Karthik Nayak wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > > diff --git a/odb/source-packed.c b/odb/source-packed.c
> > > index 12e785be48..f81a990cbd 100644
> > > --- a/odb/source-packed.c
> > > +++ b/odb/source-packed.c
> > > +	CALLOC_ARRAY(packed, 1);
> > > +	odb_source_init(&packed->base, parent->base.odb, ODB_SOURCE_PACKED,
> > > +			parent->base.path, parent->base.local);
> > > +	packed->files = parent;
> > > +	strmap_init(&packed->packs_by_path);
> > > +
> > > +	packed->base.free = odb_source_packed_free;
> > > +
> > > +	if (!is_absolute_path(parent->base.path))
> > > +		chdir_notify_register(NULL, odb_source_packed_reparent, packed);
> > > +
> > 
> > Tangent: seems like no one sets the 'name' field within
> > `chdir_notify_register()`. It is meant for tracing purposes, but if no
> > one is using it, we might as well remove it...? Perhaps #leftoverbits
> 
> There are some callers: `chdir_notify_reparent()` calls
> `chdir_notify_register()` with a name, and the reference backends call
> that function with names.
> 
> Ultimately though I think that this infrastructure is somewhat misguided
> overall: we use this to update relative paths after chdir(3p), but if we
> stored absolute paths in the first place then we wouldn't have to care
> about the paths changing at all.
> 
> I plan to revisit this infra for the object database going forward: we
> expose and use `struct odb_source::path` in various other subsystems,
> including user-facing ones. This is inherently wrong though, as there
> may be sources that don't even have an on-disk path. So there's a need
> to drop that field and make it an internal implementation detail of the
> source's backend. And once we've done that, we can just as well start to
> store absolute paths.
> 
> For the reference backends we can already do that refactoring now-ish.
> I'll send a patch series later today.

Well, as ever so often I went down the rabbit hole and discovered way
more than I wanted:

  - We never free the `struct repository::refs_private` field.

  - We create the refdb multiple times in case we have "onbranch"
    conditionals and never free them.

  - The chicken-and-egg problem we have with "onbranch" and refdb
    creation is awkward.

So I'm now sitting at 11 patches to fix all of those bugs, and I'll also
have to make changes to "setup.c" to fix them. So I'll first have to
wait for ps/setup-centralize-odb-creation to land.

Patrick