Re: [PATCH 1/4] odb: decouple source path comparisons from `the_repository`

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