On Thu, Aug 21, 2025 at 09:39:07AM +0200, Patrick Steinhardt wrote:
> While the logic is hosted in "packfile.c", it clearly reaches into other
> subsystems that aren't related to packfiles.
>
> Split up the responsibility and introduce `odb_reprepare()` which now
> becomes responsible for repreparing the whole object database. The
> existing `reprepare_packed_git()` function is refactored accordingly and
> only cares about reloading the packfile store now.
Makes sense.
> diff --git a/odb.c b/odb.c
> index 80ec6fc1fa..37ed21f53b 100644
> --- a/odb.c
> +++ b/odb.c
> @@ -694,7 +694,7 @@ static int do_oid_object_info_extended(struct object_database *odb,
>
> /* Not a loose object; someone else may have just packed it. */
> if (!(flags & OBJECT_INFO_QUICK)) {
> - reprepare_packed_git(odb->repo);
> + odb_reprepare(odb->repo->objects);
> if (find_pack_entry(odb->repo, real, &e))
> break;
> }
> @@ -1039,3 +1039,26 @@ void odb_clear(struct object_database *o)
>
> string_list_clear(&o->submodule_source_paths, 0);
> }
> +
> +void odb_reprepare(struct object_database *o)
OK; so here is the new location for the non-packfile related portions of
the former reprepare_packed_git() function. That makes sense, but...
> +{
> + struct odb_source *source;
> +
> + /*
> + * Reprepare alt odbs, in case the alternates file was modified
> + * during the course of this process. This only _adds_ odbs to
> + * the linked list, so existing odbs will continue to exist for
> + * the lifetime of the process.
> + */
> + o->loaded_alternates = 0;
> + odb_prepare_alternates(o);
> +
> + for (source = o->sources; source; source = source->next)
> + odb_clear_loose_cache(source);
> +
> + o->approximate_object_count_valid = 0;
> +
> + packfile_store_reprepare(o->packfiles);
> +
> + obj_read_unlock();
...I think I am missing where we call odb_read_lock(). The function
packfile_store_reprepare() has a comment that it must be called under
the odb_read_lock(), but I don't see where we acquire that lock here.
Are the callers of odb_reprepare() supposed to acquire that lock? If so,
it seems a little awkward that the caller is supposed to acquire the
lock, but the callee is the one to release it. Is this function missing
a odb_read_lock() at the top?
I looked at a few callers here and none of them seem to be holding this
lock. pthread_mutex_unlock() is supposed to check that the mutex lock is
held for recursive and error-checking mutexes. IIRC we initialize the
the odb mutex with PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, so I am a
little surprised that this did not cause a runtime error.
The rest of the patch looks good.
Thanks,
Taylor
