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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.