Unexpected tag chosen by git describe

[Andrew Fuller <afuller@teradici.com>]

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