Patrick Steinhardt <ps@xxxxxx> writes: > commit graphs are currently stored on the object database level. This > doesn't really make much sense conceptually, given that commit graphs > are specific to one object source. Furthermore, with the upcoming > pluggable object database effort, an object source's backend may not > evene have a commit graph in the first place but store that information > in a different format altogether. > > This patch series prepares for that by moving the commit graph from > `struct object_database` into `struct odb_source`. Hmph, I am finding the above hard to agree with at the conceptual level. In some future, we may use multiple object stores in a single repository. Perhaps we would be storing older parts of history in semi-online storage while newer parts are stored in readily available storage. But the side data structure that allows us to quickly learn who are parents of one commit is without having to go to the object store in order to parse the actualy commit object can be stored for the entire history if we wanted to, or more recent part of the history but not limited to the "readily available storage" part. IOW, where the boundary between the older and the newer parts of the history lies and which commits the commit graph covers should be pretty much independent. So moving from object_database (i.e. the whole world) to individual odb_source (i.e. where one particular subset of the history is stored) feels like totally backwards to me. Surely, a commit graph file may be defined over a set of packfiles and remaining loose object files, but it is not like an instance of the commit-graph file is tied to packfiles in the sense that it uses the index into some packfile instead of the actual object names to refer to commits, or anything like that (this is quite different from other files that are very specific to a single object store, like midx that is tied to the packfiles it describes).
