From: Derrick Stolee Date: Mon, 02 Nov 2026 17:52:23 GMT Subject: Re: [PATCH] describe: count the distance correctly when commit dates are skewed Message-ID: In-Reply-To: On 11/2/2026 12:03 PM, Junio C Hamano wrote: > Derrick Stolee 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