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