Re: [PATCH 0/6] odb: track commit graphs via object source

From: Derrick Stolee <stolee@gmail.com>
Date: Sep 8, 2025, 14:46 UTC
Message-ID: <4e67fb02-bbbb-4cd8-9892-6f65b4f82b26@gmail.com>
In-Reply-To: <aL67U0-tw7O-y6_X@pks.im>

On 9/8/2025 7:17 AM, Patrick Steinhardt wrote:

> I (probably unsurprisingly :)) don't quite agree with this.

I think I can summarize the main point you seem to be making with this quote:

> So I would claim that the commit graph is specifically tied to the
> actual storage format of objects, and it's not at all obvious that it
> would need to exist if we had a different storage format.

I think I agree in principle, if you are saying "different storage format" means "different commit object information" which then means we are talking about a completely different object type that is not at all compatible with current Git.

You could store commit and object data in SQLite, in the cloud, or via plaintext files on disk. As long as the data is still representing commit objects as we format them today, the commit-graph is still a cache that can be used as a faster way to fill 'struct commit' objects in memory without navigating to that object database.

And you also mention that the commit-graph format itself could be more efficient. You're right! I think the way we did it within Azure DevOps is more efficient, because most of the commit walking algorithms are built working directly on the integer labels within the in-memory data structure instead of operating on commit structs. This allows for less overhead when loading the graph (it's already cached in memory) and when walking thousands of commits (we only translate to object IDs if they are important for the output). But this is all the more reason to keep the commit-graph structures outside of "the object store" since a "commit-graph database" can be implemented without being tied to an object store.

If you are saying "but our existing commit-graph format puts it in 'objects/info/commit-graph[s]'" then yes the storage of a commit-graph is tied to our storage of objects. But the way we interact with it in code is in some way a layer above that.

Thanks, -Stolee