Re: [BUG] "git describe --match" performance

> 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. :)