Re: [PATCH 00/13] odb/source-files: move alternates into the backend

[Patrick Steinhardt <ps@pks.im>]

On Tue, Oct 06, 2026 at 01:53:24PM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Hi,
> >
> > Originally, when designing pluggable object databases the goal was that
> > the object database can have multiple sources, and every source attached
> > to it could use a different backend. This would have allowed for quite a
> > lot of flexibility, as you could trivially mix and match different kinds
> > of object storages in whatever way you like.
> >
> > But while well-intentioned, this design led to a bunch of conceptual
> > problems:
> >
> >   - We're now trying to read objects in source order, whereas we
> >     previously tried to read objects via packfiles before trying to read
> >     them via loose objects. This led to a performance regression when
> >     using alternates or when using a quarantine directory.
> >
> >   - Some data structures are supposed to only ever exist once, like for
> >     example bitmaps and commit graphs. At the same time, those data
> >     structures also span across the union of all objects, so they may
> >     cross sources.
> >
> >   - It is unclear how we can extend GIT_OBJECT_DIRECTORY or
> >     GIT_ALTERNATE_OBJECT_DIRECTORIES to become backend-agnostic in a
> >     backwards-compatible way. In general, introducing an object storage
> >     extension into the current status quo where alternates may have to
> >     be extended to become generic was proving to be painful.
> >
> >   - Some mechanisms of alternates assume way too much about how exactly
> >     their backends work. Alternate refs for example assume that the
> >     alternate is backed by a filesystem path, and that this filesystem
> >     path may also allow us to read references. This is not a given
> >     though, as backends may not even have local data at all.
> >
> > In short, there are a bunch of conceptual mismatches when we have
> > alternates and pluggable object databases coexist. So while the original
> > idea was nice, it does not result in a system that is easy to reason
> > about.
> >
> > This patch series corrects course by moving alternates into the "files"
> > backend itself so that they become another implementation detail. It's
> > unfortunately on the bigger side, and I'm sorry about that, but I
> > couldn't really find a way to split it up further in a sensible way.
> 
> I went through the series, took attention split over two days. The
> changes look good to me, but would definitely like to see another review :)

Thanks for your review!

Patrick