git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>
Subject: Re: What's cooking in git.git (May 2025, #07; Fri, 23)
Date: Fri, 30 May 2025 11:47:53 +0200	[thread overview]
Message-ID: <aDl-yd2fh4qVRB_V@pks.im> (raw)
In-Reply-To: <shpx4piigp5sqgpbzx4vdgu4zdn7z3ykxhu2cdyjh5vpr6zbqb@rf2sxg6hukpd>

On Tue, May 27, 2025 at 02:45:43PM -0500, Justin Tobler wrote:
> On 25/05/27 09:50AM, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > > I think the only outstanding discussion is whether to name things
> > > `odb_alternate` or `odb_source` [1]. In case others agree that
> > > `odb_source` is a better name I'm happy to revise, but if not I'd rather
> > > keep it as-is.
> > 
> > The model in which the term "alternates" was born is "A repository
> > has its own object directory, the primary one, and in addition it
> > can borrow from zero or more alternate object directories that are
> > used by other repositories".  The presence of the primary makes the
> > word "alternate" meaningful.
> > 
> > Is the model now "A repository has one object store, which consists
> > of one or more X, all of which are equals"?  If there is no primary
> > that is more special than others, then calling X an "alternate" may
> > indeed sound funny, although (1) I do not find it terribly confusing
> > and (2) I do not find "source" much better, either.
> 
> My understanding is that the object store still has a primary X and zero
> or more alternative X. The idea is that eventually, with pluggable ODBs,
> X can be a different backend/provider instead of just being "files". If
> this is the case, calling X an "alternate" would mean we have a primary
> "alternate" and potentially a set of "alternate" alternates.
> 
> This sounds a bit odd and doesn't quite match what I would intuitively
> expect. But, I also don't find it super confusing either.

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.

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

> > The names we use to call the collection and the underlying
> > implementations of the collection in the reference world
> > unfortunately does not quite help to guide us, as we do not take two
> > implementations and compose into one unified view, which is what we
> > are doing in the object store.  Hmmm...
> 
> Similar to references, I still think of a pluggable ODB as a "backend".
> The main difference being that with references there is only a single
> backend active ("file" or "reftables") at a time, while for the object
> store there could be multiple.

Yeah, that's basically the major source of confusion I want to avoid
with the "backend" terminology. I really do want to make it explicit
that there is not only one backend, but multiple ones.

Patrick

  reply	other threads:[~2025-05-30  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-24  2:16 What's cooking in git.git (May 2025, #07; Fri, 23) Junio C Hamano
2025-05-27  8:15 ` Patrick Steinhardt
2025-05-27 16:50   ` Junio C Hamano
2025-05-27 19:45     ` Justin Tobler
2025-05-30  9:47       ` Patrick Steinhardt [this message]
2025-05-30 16:28         ` Junio C Hamano
2025-06-02  6:42           ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aDl-yd2fh4qVRB_V@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jltobler@gmail.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).