Re: [PATCH v2 04/17] odb/source-inmemory: implement `read_object_info()` callback

[Patrick Steinhardt <ps@pks.im>]

On Thu, Apr 09, 2026 at 05:40:01AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/odb/source-inmemory.c b/odb/source-inmemory.c
> > index ccbb622eae..12c80f9b34 100644
> > --- a/odb/source-inmemory.c
> > +++ b/odb/source-inmemory.c
> > @@ -1,5 +1,57 @@
> >  #include "git-compat-util.h"
> > +#include "odb.h"
> >  #include "odb/source-inmemory.h"
> > +#include "repository.h"
> > +
> > +static const struct cached_object *find_cached_object(struct odb_source_inmemory *source,
> > +						      const struct object_id *oid)
> > +{
> > +	static const struct cached_object empty_tree = {
> > +		.type = OBJ_TREE,
> > +		.buf = "",
> > +	};
> > +	const struct cached_object_entry *co = source->objects;
> > +
> > +	for (size_t i = 0; i < source->objects_nr; i++, co++)
> > +		if (oideq(&co->oid, oid))
> > +			return &co->value;
> > +
> > +	if (oid->algo && oideq(oid, hash_algos[oid->algo].empty_tree))
> > +		return &empty_tree;
> > +
> 
> Silly questiong, would it make more sense to check for empty_tree before
> iterating over all objects?
> 
> The rest looks good

Maybe? I guess for now reading the empty tree is the most important use
case we have for the in-memory backend, as we only write in-memory
objects in a single caller. On the other hand, `source->objects_nr`
would be zero in all the other cases, and jumping over the loop should
be fast enough to not matter in practice.

An alternative I was thinking about is to store the empty tree the same
way as we store all the other objects so that we don't have to special
case anything. That has the benefit that we can actually modify the tree
object, too, which may eventually become relevant with regards to an
object's mtime that we may want to update. The downside is that we have
another allocation here and need to eagerly initialize the data
structure that stores the objects.

Patrick