Benno Evers <benno@xxxxxxxxxx> writes: > When searching the commit graph for tag candidates, `git-describe` > will stop as soon as there is only one active branch left and > it already found an annotated tag as a candidate. > > This works well as long as all branches eventually connect back > to a common root, but if the tags are found across branches > with no common ancestor > > B > o----. > \ > o-----o---o----x > A > > it can happen that the search on one branch terminates prematurely > because a tag was found on another, independent branch. This scenario > isn't quite as obscure as it sounds, since cloning with a limited > depth often introduces many independent "dead ends" into the commit > graph. > > The help text of `git-describe` states pretty clearly that when > describing a commit D, the number appended to the emitted tag X should > correspond to the number of commits found by `git log X..D`. To be fair, that description was written for the case in a normal history with only a single root. 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? Thanks.
