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

[Derrick Stolee <stolee@gmail.com>]

On 11/2/2026 12:03 PM, Junio C Hamano wrote:
> 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?

I do like this idea, as we could take the structure that was
computed and write it out with relatively small overhead at
that point. We are expecting the commit-graph to exist in
more places, and it has been baking for several years now.
Maybe it's time to make that expectation more explicit and
have it become an opt-out instead of opt-in feature.

It does lead to some concerns that commands that are "read
only" become mutators of disk state. This is something that
could be rectified with appropriate guardrails.

Thanks,
-Stolee