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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox