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

[Michael J Gruber <git@drmicha.warpmail.net>]

Johannes Sixt venit, vidit, dixit 21.09.2010 14:34:
> Am 9/21/2010 14:10, schrieb Michael J Gruber:
>> Johannes Sixt venit, vidit, dixit 21.09.2010 14:00:
>>> Am 9/21/2010 13:49, schrieb Michael J Gruber:
>>>> 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?
>>
>> I don't consider the existing behaviour wrong, though it may be a bit
>> tough to figure out. It may even be that the depth calculation has an
>> off-by-1 error which leads to this behaviour.
> 
> I faintly recall that the current behavior was already made

Better faintly than faintingly ;)

> --first-parent-like on purpose, exactly for cases like Joshua's and the
> one I cited. Why does it work with mine, but not with Joshua's?
> 
> Notice that v1.7.0.7 is an immediate parent of e5498e8a, but still its
> calculated "depth" is much higher than for v1.7.1.1, which is 25 commits
> down in the history. Why? Why isn't it the same with Joshua's history? Is
> it due to the commit dates? Or the tag dates?


By experimentation (inserting additional tag-less commits, not changing
topology), I can make v2.0-base have the same, lower or higher depth
than v1.1-stable.

In fact, the (commit) date order is important here: For describing
<commit>, "describe" builds a 1 item list with commit, pops it, inserts
its parents in date order (!), looks at each item in that order, in each
step again inserting the parents in date order. So, it's really that the
branch with more newer commits wins (this is a lousy description, but
you get the idea).

Reading commit messages like 80dbae makes me think that this was
intended; and it is completely different from a first-parent approach.
So I think the default really is a good default as is, and first-parent
is useful and different in some cases.

Michael