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

[Junio C Hamano <gitster@pobox.com>]

Kristofer Karlsson <krka@spotify.com> writes:

> 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

Unbelievably bad clock skew.  I wonder if these people do not check
their machine clock at all, but knowing the answer to that or learning
why they don't would not help the issue at hand at all, so I'll stop.

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

Sounds interesting to me.

Thanks.