From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/4] odb: decouple source path comparisons from `the_repository`
Date: Wed, 12 Aug 2026 07:39:11 +0200 [thread overview]
Message-ID: <anwG_yIy0eNsZi2n@pks.im> (raw)
In-Reply-To: <anuP0Mh9aBz9VdBK@denethor>
On Tue, Aug 11, 2026 at 05:04:58PM -0500, Justin Tobler wrote:
> On 26/08/10 03:33PM, Patrick Steinhardt wrote:
> > When registering alternates we deduplicate object database sources by
> > their path so that the same source won't be added twice. Ever since
> > cf2dc1c238 (speed up alt_odb_usable() with many alternates, 2021-07-07)
> > this duplicate check is backed by a map keyed by the source's path,
> > using `fspathhash()` and `fspatheq()` as hash and equality functions,
> > respectively.
> >
> > These functions are problematic in this context for two reasons:
> >
> > - They implicitly depend on `the_repository` instead of the
> > repository that owns the object database.
> >
> > - They derive case-sensitivity from `repo_ignore_case()`, which
> > returns a default value in case the repository's configuration has
> > not been parsed yet. Object database sources may be registered
> > before that is the case, so the answer may flip depending on when a
> > source gets registered.
>
> Are alternates currently always registered after repository
> configuration has been parsed? Or is this an existing bug?
They are, because of the lazy-loading. So this is not a bug, we merely
have to ensure that we retain this behaviour.
> > Overall it's quite debatable whether all of this complexity really is
> > worth it, or whether we should just linearly search through all sources
> > to find duplicates. But the mentioned commit cares about cases with
> > thousands of alternates, and a linear search would of course regress
> > performance quite a bit. This doesn't really feel like a reasonable case
> > to care about though, but I don't feel comfortable regressing it anyway.
>
> Ya, my first though here was also whether all of this song and dance is
> really needed for alternates. There may be someone out there with tons
> of alternates I guess though. Probably good to be on the safe side.
cf2dc1c238 (speed up alt_odb_usable() with many alternates, 2021-07-07)
mentions a repository with 100k alternates in total, but that's an
artificial testing setup. I doubt you can get any kind of reasonable
performance out of such a repository, regardless of whether on not
parsing the alternates is going to be fast.
For now though I didn't want to remove this infra. It feels overblown,
but it's not an unmaintainable mess, either.
Patrick
next prev parent reply other threads:[~2026-08-12 5:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 13:33 [PATCH 0/4] odb: eagerly load alternates Patrick Steinhardt
2026-08-10 13:33 ` [PATCH 1/4] odb: decouple source path comparisons from `the_repository` Patrick Steinhardt
2026-08-11 22:04 ` Justin Tobler
2026-08-12 5:39 ` Patrick Steinhardt [this message]
2026-08-10 13:33 ` [PATCH 2/4] odb: eagerly initialize alternates Patrick Steinhardt
2026-08-11 22:15 ` Justin Tobler
2026-08-12 5:39 ` Patrick Steinhardt
2026-08-10 13:33 ` [PATCH 3/4] odb: drop `loaded_alternates` field Patrick Steinhardt
2026-08-11 22:22 ` Justin Tobler
2026-08-10 13:33 ` [PATCH 4/4] odb: drop `alternates_db` field Patrick Steinhardt
2026-08-11 22:31 ` Justin Tobler
2026-08-12 5:39 ` Patrick Steinhardt
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=anwG_yIy0eNsZi2n@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
/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