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

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

Derrick Stolee <stolee@gmail.com> writes:

>>> +	struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
>>>  	struct commit_name *n;
>>>  	struct possible_tag all_matches[MAX_TAGS];
>>>  	unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
>> 
>> ... I wonder whether we should also call `ensure_generations_valid()`
>> here. That function is very expensive in cases where we don't have a
>> commit graph as it backfills generation numbers, and it may have to walk
>> the complete commit graph to do so. But isn't that better compared to
>> silently yielding a potentially-wrong result?
> I came here to say exactly that. Even when a commit-graph exists, it can
> be slightly behind the object database and so we need to fix up the
> newest commits with generation number details.
>
> The biggest downside is that it becomes very slow when a commit-graph
> doesn't exist (it walks all reachable commits from the starting points)
> but that's typically better than giving an incorrect answer.

When we ended up spending the huge cost by doing this in a
repository without existing commit-graph or with an out of date
commit-graph, I wonder if it is possible to recoup the cost by
amortizing it over time by writing a commit-graph out?