From: Junio C Hamano Date: Mon, 02 Nov 2026 17:03:25 GMT Subject: Re: [PATCH] describe: count the distance correctly when commit dates are skewed Message-ID: In-Reply-To: <8fa4010d-d39f-4e78-ab01-be3e9d20a148@gmail.com> 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?