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
next prev parent 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).