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

From: Derrick Stolee <stolee@gmail.com>
Date: Nov 2, 2026, 14:20 UTC
Message-ID: <8fa4010d-d39f-4e78-ab01-be3e9d20a148@gmail.com>
In-Reply-To: <auiGP4XhObUzC9vD@pks.im>

On 11/2/2026 7:46 AM, Patrick Steinhardt wrote:

> On Fri, Oct 30, 2026 at 11:55:03PM -0700, Linus Torvalds wrote:
>> From: Linus Torvalds <torvalds@linux-foundation.org>

Show 19 quoted lines

>> diff --git a/builtin/describe.c b/builtin/describe.c
>> index c0abc931a5..2cd597d919 100644
>> --- a/builtin/describe.c
>> +++ b/builtin/describe.c
>> @@ -328,7 +328,7 @@ static void append_suffix(int depth, const struct object_id *oid, struct strbuf
>>  static void describe_commit(struct commit *cmit, struct strbuf *dst)
>>  {
>>  	struct commit *c, *gave_up_on = NULL;
>> -	struct prio_queue queue = { compare_commits_by_commit_date };
>> +	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.

Thanks, -Stolee