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

[Patrick Steinhardt <ps@pks.im>]

On Thu, Apr 09, 2026 at 06:46:30AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> 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.
> 
> Doesn't 
> 
>     git grep -E -e 'in[- ]?core' -- ':!Documentation/RelNotes' ':!t'
> 
> give many hits that we want to be in line with in the codebase
> anyway, and even in some user-facing things?  I just noticed an
> option "--no-kept-objects=in-core" (which I didn't know about ;-).

Most of the hits are in our code though, and end users wouldn't
typically see those. So what I think is more relevant is documentation
or options like the one you pointed out. But "--no-kept-objects=" is not
even documented, which basically leaves us with the following hits:

  Documentation/gitformat-pack.adoc:write a cruft pack. Crucially, the set of in-core kept packs is exactly the set
  Documentation/technical/parallel-checkout.adoc:parallelize the work of uncompressing the blobs, applying in-core
  Documentation/technical/racy-git.adoc:because in-core timestamps can have finer granularity than
  Documentation/technical/racy-git.adoc:([PATCH] Sync in core time granularity with filesystems,

I think that these hits are all related to what we're doing here, as
we're talking about object data that we handle in-core.

I initially said "it's not any different", but thinking a bit more about
it I think there is a slight difference: in-core could be any object
that we have parsed from the object database, even if it's backed by an
actual on-disk object. In-memory objects may not even have been parsed
at all, so technically speaking they may not even be in-core.

So in summary:

  - I think that end users have not really been exposed to the concept
    of "in-core".

  - The concepts of "in-core" and the ODB source here are slightly
    different, as any object is treated as "in-core" that has been
    parsed.

  - The concept of "in-memory" is easier for the end user to understand
    in the context of the ODB, as it's a more general concept compared
    to the very Git-specific "in-core" term".

Hope that makes sense :)

Thanks!

Patrick