Re: can git-describe learn first-parent behavior?

Am 9/21/2010 13:49, schrieb Michael J Gruber:

Johannes Sixt venit, vidit, dixit 21.09.2010 12:03:

quoted

git describe e5498e8a^2 e5498e8a^1~24 e5498e8a
v1.7.0.7
v1.7.1.1
v1.7.1.1-38-ge5498e8

v1.7.1.1 is 25 commits away, while v1.7.0.7 is a parent (the second).

AFAICS, git-describe does The Right Thing (--first-parent).

I'm not saying it does the wrong thing. I'm saying it does not do
--first-parent but depth priority (where depth is a bit complicated),
which may or may not be the same as first-parent transversal/priority.
You picked one case where they coincide:

git describe --debug e5498e8a^2 e5498e8a^2~24 e5498e8a
v1.7.0.7
v1.7.0.5

This should be "v1.7.1.1", no?

searching to describe e5498e8a
 annotated         38 v1.7.1.1
 annotated        252 v1.7.1
 annotated        268 v1.7.1-rc2
 annotated        318 v1.7.1-rc1
 annotated        355 v1.7.1-rc0
 annotated        478 v1.7.0.7
 annotated        492 v1.7.0.6
 annotated        512 v1.7.0.5
 annotated        539 v1.7.0.4
 annotated        564 v1.7.0.3
traversed 1267 commits
more than 10 tags found; listed 10 most recent
gave up search at 97222d9634b5518cd3d328aa86b52746a16334a7
v1.7.1.1-38-ge5498e8

v1.7.1.1 clearly wins by depth priority.

If "depth priority" is not the shortest ancestry path (and it obviously is
not given the numbers above), what is it then, and why does it not work
with Joshua's example? Wouldn't it be better to make it Just Work instead
of adding a workaround that has to be enabled manually?

-- Hannes