On Mon, Jun 08, 2026 at 08:29:04AM -0700, Karthik Nayak wrote:

Patrick Steinhardt [off-list ref] writes:

quoted

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.

Patrick