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

> 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.