Re: [PATCH 2/2] commit-graph: propagate topo_levels slab to all chain layers

[Patrick Steinhardt <ps@pks.im>]

On Fri, Jul 10, 2026 at 03:14:28PM -0700, Taylor Blau wrote:
> On Tue, Jul 07, 2026 at 04:57:13PM +0200, Kristofer Karlsson wrote:
> > (b) Move topo_levels to struct object_database. Since
> > fill_commit_graph_info() can already reach the odb via
> > g->odb_source->odb, no signature changes are needed.
> > The write side becomes a single assignment:
> >
> >     ctx.r->objects->topo_levels = &topo_levels;
> >
> > and cleanup becomes:
> >
> >     ctx.r->objects->topo_levels = NULL;
> >
> > No chain walk needed and the diff is fairly small.
> > I am not sure about the semantics of it though -- should the odb
> > have a reference to topo_levels?
> 
> This seems to be the most promising approach, though I'd be curious what
> Patrick's thoughts are. The commit-slab API is really a property of the
> object database, but we treat these as a global as I do not recall them
> yet being touched by the ODB refactoring effort.

I was investigating several times whether we can remove them from global
scope and move them into the object database indeed. The answer is that
it's somewhat complicated because we reuse the slab for multiple
different things, and detangling that has proven to be a bit of a mess.

The other question here is whether commit graphs really are a property
of the object database itself, or whether they are rather a property of
a given backend. Sure, we can only have a single commit graph at any
point in time, so they feel like they are at the object database level.
But is the current implementation of a commit graph really the best for
all potential backends out there?

If you take for example a distributed backend to store objects, then you
probably don't want to have a single local commit graph that is stored
in ".git/objects/info". Furthermore, the current format may not even be
the best one to store the cached information, either.

So ultimately, I can see one of two approaches:
 
  - Either we make the commit graph itself pluggable as a standalone
    mechanism, too.

  - Or we treat it as a property of the object backend.

I haven't fully made up my mind yet. But I guess detangling the current
mess that we have with the commit graphs would help regardless of which
direction we eventually go into.

Thanks!

Patrick