On Friday, September 22, 2023 1:52 PM, Junio C Hamano wrote: ><rsbecker@xxxxxxxxxxxxx> 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.
