On Fri, May 30, 2025 at 09:28:13AM -0700, Junio C Hamano wrote:

Patrick Steinhardt [off-list ref] writes:

quoted

Yeah, I understand that confusion indeed. I don't think that the other
proposals we've got are a lot better, either:

  - `odb_backend` was shot down because it may cause the association
    that one object database has one backend. But backends are per
    alternate, so there's a mismatch in expectations.

I do not see where that association would come from, though.  But I
agree with the other objection that the word "backend" is more about
implementation and less about an instance that is realized by that
implementation, i.e. two such components that runs the code for a
single backend may be part of a single object database.

quoted

  - `odb_source` is better, but we now have the problem that we use
    "alternate" interchangably in most cases where we also use
    `odb_source`. This will likely lead to somewhat awkward interfaces.

The problem with `odb_source` might eventually go away once we clearly
distinguish the "alternates" concept from the low-level mechanism to
access objects. But I'm just not certain at all whether it won't cause
more confusion when in most cases "alternates" and "sources" can be used
somewhat interchangably.

I dunno. The more I think about this the more I start to like the
`odb_source` name.

Yeah, I do not mind calling the instantiation backed by a backend
implementation a odb_source.

In any case, when deciding the terminology, we should look at what
we currently have in the glossary and imagine how they should look
like in the updated world.  Currently,

 - "alternate object database" is described as inheriting the
   entirety of another "object database" (we deliberately do not say
   that this other object database belongs to another repository, as
   a standalone object database is a valid option).

 - "object database" is described as what holds a set of "objects".
   There is no complication here ;-)

When treating the set of objects stored in $GIT_DIR/objects/??/
directories (i.e. "loose objects") and the set of objects stored in
$GIT_DIR/objects/pack/ directory (i.e. "packed objects") as two
separate odb_something, with a vision that we may add different
implementations of such collection later, it would be very confusing
to call each of them "an alternate".  "source" may not be ideal, but
it is the best among what we collectively have come up with, I think.

Okay, let's settle on `odb_source` then. I'll send a new version once I
have wrangled all the conflicts :) Thanks for the discussion, all!

Patrick