RE: [BUG] `git describe` doesn't traverse the graph in topological order

[<rsbecker@nexbridge.com>]

On Friday, September 22, 2023 1:52 PM, Junio C Hamano wrote:
><rsbecker@nexbridge.com> writes:
>
>> There appears to be a merge at 446120fd88 which brings v9.3.0.rc0 closer
to HEAD
>than v9.3.0.rc1.
>
>I didn't look at the actual graph but let me say I trust you ;-)
>
>I wonder if there should be an obvious "explain why you gave this name"
mode added
>to the command, though.  The command should be able to say "The closest
path from
>HEAD to any tag is via this, that, and that commit, which is N hops to tag
T0", and
>from there, the user should be able to say "Oh, I thought T1 was closer,
let me try
>again to describe HEAD, limiting the candidate only to T1" and run the
command in
>that mode, which should be able to say "The closest path from HEAD to any
tag that
>is allowed as a candidate is via these commits, which is M hops to tag T1".
And if M
>is smaller than N, then that may deserve to trigger a bug report (but as
you said,
>there are rules like preferring annotated over unannotated tags involved,
so it may
>not as straight-forward as comparing the two integer hop counts).
>
>Thanks for digging.

I'm wondering whether we need something more general that --first-parent.
Perhaps something like

git describe commitish [ commitish ... ]

Where the traversal must cross the set of specified commitish points in
history in order to find the expected tag. In Ben's case, I do not think
that would help much, given the complexity of his history. Perhaps a
--verbose argument might display the analysis path done by git describe as
above. Sadly, I am not familiar with this code area.

What confuses me is how, in the other subthread, that adding sleep 1 to the
construction of history should make any difference. My understanding is that
the path to the tag is invariant of the commit-date.