On Tue, Oct 06, 2026 at 01:53:24PM -0700, Karthik Nayak wrote:
Show 47 quoted lines
> 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 :)