Re: [PATCH 00/16] odb: introduce "inmemory" source

[Patrick Steinhardt <ps@pks.im>]

On Wed, Apr 08, 2026 at 02:48:52PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Fri, Apr 03, 2026 at 08:41:16AM -0700, Junio C Hamano wrote:
> >> Patrick Steinhardt <ps@pks.im> writes:
> >> 
> >> > this patch series introduces the second object database source type,
> >> > which is the "inmemory" source.
> >> 
> >> I cannot read the word without a hyphen, i.e.e.g., "in-memory".
> >
> > Fair. I think I'll keep it as `odb_source_inmemory` in the sources,
> > which I find easier ot parse than `odb_source_in_memory`, but will adapt
> > to "in-memory" in prose. I already did this for most of the part, but
> > not in the cover letter indeed.
> 
> Fair.
> 
> FWIW, we do the same for "in core" or "in-core" in prose, and
> "incore" in identifier names, so the above is understandable
> position to take.
> 
> But stepping back a bit, does this new "in memory" refer to a
> concept that is different from what the rest of the system uses "in
> core" to represent?

No, in principle it's not any different. One of the reasons I decided to
go with "in memory" though is that this backend may eventually be
(power-)user-facing via the planned "objectStorage" extension.

This extension will work similar to how the "refStorage" extension
works, where every backend has a schema followed by an optional payload.
So for the files backend it would be "files://<path>", and if one wants
to configure a temporary ODB source that doesn't store objects it would
be "inmemory://". And overall, I think that "inmemory" is a lot easier
to understand intuitively compared to "incore".

The counter argument may be that this really only is for power users
anyway, as it's a rather risky thing to do (e.g. you must not update any
refs), and such power users may understand the concept of "in-core". But
even there I feel like it makes sense to rather say "in-memory".

Patrick