Re: [PATCH v2 09/16] packfile: split up responsibilities of `reprepare_packed_git()`
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Aug 26, 2025, 02:10 UTC
- Message-ID
- <aK0XeiRz13O7j+HO@nand.local>
- In-Reply-To
- <20250821-b4-pks-packfiles-store-v2-9-d10623355e9f@pks.im>
On Thu, Aug 21, 2025 at 09:39:07AM +0200, Patrick Steinhardt wrote:
Show 7 quoted lines
> 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.
Show 19 quoted lines
> 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...
Show 20 quoted lines
> +{
> + 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