From: Benno Evers <benno@xxxxxxxxxx> > 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.
