From: Toon Claes <toon@iotcl.com>
To: Justin Tobler <jltobler@gmail.com>, Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] setup: detangle loading of loose object maps
Date: Thu, 30 Jul 2026 16:27:05 +0200 [thread overview]
Message-ID: <87pl04d03q.fsf@emacs.iotcl.com> (raw)
In-Reply-To: <amkOb3rvWFUpnT28@denethor>
Justin Tobler <jltobler@gmail.com> writes:
> On 26/07/24 05:48AM, Patrick Steinhardt wrote:
>> When a repository is configured to use a compatibility hash function
>> then we load the loose object map when we initialize the repository.
>> This object map provides the mappings between the canonical object hash
>> and the compatibility object hash.
>>
>> Loading the object map happens in `repo_set_compat_hash_algo()`, which
>> calls `repo_read_loose_object_map()` in case the compatibility object
>> hash is non-zero. This setup sequence has two major downsides:
>>
>> - We assume that the primary object database is the "files" object
>> database so that we can extract its "loose" backend. This stops
>> working with pluggable object databases.
>
> So IIUC, does this mean that `repo_set_compat_hash_algo()` is directly
> reaching into the loose object source to load the compatibility object
> map? I suppose it should be the responsibility of the respective ODB
> backend to handle object compatibility.
>
>> - We require the object database to already have been initialized when
>> configuring the object database. This means that we must intermix
>> configuration of the repository and initialization of its
>> sub-structures in a weird way.
>
> If there any reason we need to eagerly load compatibility object
> mappings?
>
>> Refactor the logic so that we instead load the loose object map via the
>> "loose" backend, which fixes both of the above issues.
>
> Sounds reasonable.
>
>> Signed-off-by: Patrick Steinhardt <ps@pks.im>
>> ---
>> loose.c | 11 +++++------
>> loose.h | 1 +
>> odb/source-loose.c | 2 ++
>> repository.c | 2 --
>> setup.c | 5 +++--
>> 5 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/loose.c b/loose.c
>> index 9dad75373b..a3b2dcedc2 100644
>> --- a/loose.c
>> +++ b/loose.c
>> @@ -61,7 +61,7 @@ static int insert_loose_map(struct odb_source_loose *loose,
>> return inserted;
>> }
>>
>> -static int load_one_loose_object_map(struct odb_source_loose *loose)
>> +int loose_object_map_load(struct odb_source_loose *loose)
>> {
>> struct repository *repo = loose->base.odb->repo;
>> struct strbuf buf = STRBUF_INIT;
>> @@ -69,6 +69,9 @@ static int load_one_loose_object_map(struct odb_source_loose *loose)
>> FILE *fp;
>> int ret = -1;
>>
>> + if (!should_use_loose_object_map(repo))
>> + return 0;
>
> Previously the above condition has asserted in
> `repo_read_loose_object_map()` which calls `loose_object_map_load()` for
> each source. Do we expect each source to potentially answer differently
> though?
I've been wondering about this as well. The reason for this change is to
also have this guard when odb_source_loose_new(), in source-loose.c (see
further down in the patch), calls this function too.
>> +
>> if (!loose->map)
>> loose_object_map_init(&loose->map);
>> if (!loose->cache) {
>> @@ -112,14 +115,10 @@ int repo_read_loose_object_map(struct repository *repo)
>> {
>> struct odb_source *source;
>>
>> - if (!should_use_loose_object_map(repo))
>> - return 0;
>> -
>> odb_prepare_alternates(repo->objects);
>> -
>> for (source = repo->objects->sources; source; source = source->next) {
>> struct odb_source_files *files = odb_source_files_downcast(source);
>> - if (load_one_loose_object_map(files->loose) < 0)
>> + if (loose_object_map_load(files->loose) < 0)
>> return -1;
>> }
>>
>> diff --git a/loose.h b/loose.h
>> index 6c9b3f4571..ed663ac550 100644
>> --- a/loose.h
>> +++ b/loose.h
>> @@ -13,6 +13,7 @@ struct loose_object_map {
>>
>> void loose_object_map_init(struct loose_object_map **map);
>> void loose_object_map_clear(struct loose_object_map **map);
>> +int loose_object_map_load(struct odb_source_loose *loose);
>> int repo_loose_object_map_oid(struct repository *repo,
>> const struct object_id *src,
>> const struct git_hash_algo *dest_algo,
>> diff --git a/odb/source-loose.c b/odb/source-loose.c
>> index 3f7d04a56e..812ca1c138 100644
>> --- a/odb/source-loose.c
>> +++ b/odb/source-loose.c
>> @@ -727,5 +727,7 @@ struct odb_source_loose *odb_source_loose_new(struct object_database *odb,
>> if (!is_absolute_path(loose->base.path))
>> chdir_notify_register(NULL, odb_source_loose_reparent, loose);
>>
>> + loose_object_map_load(loose);
>
> Now we load the loose object map for the specific source when its
> created.
Here.
--
Cheers,
Toon
next prev parent reply other threads:[~2026-07-30 14:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 3:48 [PATCH 0/5] odb: make creation of object database pluggable Patrick Steinhardt
2026-07-24 3:48 ` [PATCH 1/5] loose: load loose object map for the correct source Patrick Steinhardt
2026-07-24 17:26 ` Junio C Hamano
2026-07-28 20:14 ` Justin Tobler
2026-07-30 12:47 ` Toon Claes
2026-07-24 3:48 ` [PATCH 2/5] setup: detangle loading of loose object maps Patrick Steinhardt
2026-07-24 18:41 ` Junio C Hamano
2026-07-28 20:32 ` Justin Tobler
2026-07-30 14:27 ` Toon Claes [this message]
2026-07-24 3:48 ` [PATCH 3/5] setup: defer object database creation Patrick Steinhardt
2026-07-24 18:50 ` Junio C Hamano
2026-07-28 21:13 ` Justin Tobler
2026-07-24 3:48 ` [PATCH 4/5] odb/source: introduce function to map source type to name Patrick Steinhardt
2026-07-26 20:34 ` Junio C Hamano
2026-07-24 3:48 ` [PATCH 5/5] odb: make creation of on-disk structures pluggable Patrick Steinhardt
2026-07-26 20:42 ` Junio C Hamano
2026-07-28 21:23 ` Justin Tobler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pl04d03q.fsf@emacs.iotcl.com \
--to=toon@iotcl.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.