Re: [PATCH] describe: dont abort too early when searching tags

From: benno@bmevers.de <benno@bmevers.de>
Date: Feb 25, 2020, 19:07 UTC
Message-ID: <20200225190751.5898-1-benno@bmevers.de>
In-Reply-To: <xmqq4kvfpv17.fsf@gitster-ct.c.googlers.com>

From: Benno Evers <benno@bmevers.de>

> How much, if any, does this change hurt the performance by forcing
> the code to dig further if there aren't multiple roots?  If there is
> such an unnecessary overhead that degrades performance for the more
> common case, can we improve it further to avoid it?

If there aren't multiple roots, then this should be visiting exactly the same number of commits as before. This is because in this case, if we're down to a single branch, the current commit must be an ancestor of *all* tag candidates so the stopping condition is always true.

It's actually a bit challenging to find good test repositories for
this in the wild, as the big ones that use a merging workflow (like git
itself, the kernel, etc.) usually have so many branches active at any
point in time that the search will only stop when it hits the max number
of candidates. So I might be missing some edge cases. However, for the
"normal" repositories that I tested the number of traversed commits was
always the same before and after the change.