Twice now we've found ourselves in a situation where git describe chooses a tag that we weren't expecting. I'm wondering if this is an obscure bug, or whether somehow We're Doing It Wrong. $ git --version git version 2.25.1 $ git describe --debug --candidates=10 describe HEAD No exact match on refs or tags, searching to describe annotated 432 release/20.01.1 annotated 71 release/20.04.0-rc9 annotated 75 release/19.11.2 annotated 77 release/20.04.0-rc8 annotated 79 release/20.04.0-rc7 annotated 85 release/20.04.0-rc6 annotated 87 release/20.04.0-rc5 annotated 91 release/20.04.0-rc4 annotated 94 release/2.14.7-rc1 annotated 121 release/20.04.0-rc3 traversed 866 commits more than 10 tags found; listed 10 most recent gave up search at 704bbef36b7f66ea0d56ecf4fe1ad9812dfb126a release/20.01.1-432-gd11dd98b90 $ git describe --debug --candidates=11 describe HEAD No exact match on refs or tags, searching to describe annotated 71 release/20.04.0-rc9 annotated 77 release/20.04.0-rc8 annotated 79 release/20.04.0-rc7 annotated 83 release/20.01.1 annotated 85 release/20.04.0-rc6 annotated 87 release/20.04.0-rc5 annotated 91 release/20.04.0-rc4 annotated 113 release/19.11.2 annotated 121 release/20.04.0-rc3 annotated 159 release/2.14.7-rc1 annotated 171 release/20.04.0-rc2 traversed 634 commits more than 11 tags found; listed 11 most recent gave up search at 65df08f972d970f0e85dfa5503cb02b48c9238ec release/20.04.0-rc9-71-gd11dd98b90 So when git describe looks for the 10 most "recent" (I don't claim to know whether that means date, shortest commit distance, fewest commit delta, etc) it finds release/20.01.1 with a weight of 432 and tagged recently and chooses that over release/20.04.0-rc9 which is only weighted 71, but tagged at an earlier time. Here git describe chose the highest weighted tag when instead we were expecting the lowest weighted tag. However when git describe looks for the 11 most recent, the weightings of some of the tags are actually different. release/20.01.1 drops from 432 down to 83, and release/19.11.2 rises from 75 to 113. And then the tag with the lowest weighting is chosen. We're happy with this result. So my question is why is the distant (but fresh) release/20.01.1 tag chosen by git describe when candidates=n is low but we get the tag we expect when candidates=n is high, even though both tags were considered in both scenarios? A bug or PEBKAC? Thanks, -Andrew
