Re: [PATCH] describe: count the distance correctly when commit dates are skewed

> What remains is knowing when to stop.  With the queue ordered by
> generation number, as in Linus's patch, that is exact for commits in
> the commit-graph.  For commits outside of it, it is exact as long as
> no commit is dated more than some epsilon before one of its own
> ancestors.  That is a sufficient condition, not a necessary one: on
> linux.git the worst such case since v6.0 is about 60 days, but a

> miscount also needs the skew to be right where the walk stops, and
> an epsilon of a week gave exact depths for every commit I tried,
> including the ones right around the skewed spots, at no measurable
> cost.
>
> A nice property is that this also works well with a partial
> commit-graph.  The commits outside of it are visited first, and only
> those rely on the epsilon; once the walk reaches the commits in it,
> it can stop as soon as the depths are final.  So the commit-graph
> does not need to be fully up to date to help, much like with other
> walks that use generation numbers.
>
> For 2a500a04d6f9 it gives v7.3-19059 with and without a
> commit-graph, in about the same time as master, and it matches
> "rev-list --count" on the ~450 commits of the last merge window.
> Both expected failures in t6120 pass with it, with and without
> GIT_TEST_COMMIT_GRAPH.  The change is about 120 lines added and 60
> removed in builtin/describe.c.
>
> Would this be worth pursuing, either instead of or on top of
> Linus's patch?  If so, I would be happy to clean it up and send it.