Git describe miscounted distance when commit dates were skewed

Linus Torvalds has fixed a long-standing failure in git describe that produced nonsense commit-distance numbers whenever commit timestamps were unreliable.

During the Linux 7.4 merge window the tool reported v7.3-19342 while the kernel's own localversion correctly counted 19059 commits after the same tag. Describe had walked past the tagged release because it ordered commits solely by date, so it tallied hundreds of commits already present in 7.3. The kernel calculation was right; describe was wrong.

The change makes describe order its walk by generation number first, falling back to commit date only as a tie-breaker. That restores the documented intent that the distance figure be the true path length from the tag. The improvement still needs a commit graph; without one, generation data may be missing and the old miscount can return.

Git maintainer Junio C Hamano accepted the patch. Patrick Steinhardt and Derrick Stolee later observed that results can now differ depending on whether a recent commit graph exists, and argued for explicitly ensuring generation numbers are valid so the answer stays correct even when the graph is absent or stale. That path is expensive on large repositories without a graph. The maintainers also floated writing a commit graph afterward to amortize the cost, while noting the awkwardness of a read-only command mutating on-disk state.

The kernel had already been computing the distance itself rather than trusting describe, which is how the mismatch became visible.