On Thu, Oct 31, 2024 at 01:05:26PM -0400, Jeff King wrote: > I think we talked long ago about computing commit-graphs over the > grafted state, and then using those graphs as long as the graft state > remained the same. But I don't think we ever implemented anything. > > Another possibility (that I don't recall we've ever discussed) is > partially using commit graphs. Some commit properties, like generation > numbers, depend on other commits. So a graft at the bottom of history is > going to rewrite the generations for all of the descendants. But we > could still use the graph information to load the parents and trees of > all of the non-grafted commits. Those are still valid even in a grafted > situation, and that's what's providing most of the speed up in this case > (without it, we're literally zlib inflating each commit we traverse in > order to find its parents, versus an integer lookup via the > commit-graph). > > That might not be _too_ hard to implement. In theory, anyway. :) Adding Stolee (CC'd), our resident commit-graph expert, to see if they have any thoughts. Thanks, Taylor
