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

> Joshua Shrader venit, vidit, dixit 21.09.2010 21:57:
>> I think I need to apologize to the list.  I did not actually observe
>> what I had stated in my original post.  Given the description (and my
>> possibly naive understanding) of git-describe, I hypothesized that
>> what I originally stated was possible. If git-describe is in fact
>> implemented with a first-parent-like behavior, as some people believe
>> to be true, then I believe it is working correctly - I've seen nothing
>> to the contrary.  However, I do believe that the documentation is
>> unclear if this is the case.  My interpretation of "depth," which I
>> believe to be consistent with the graph-theoretical definition, does
>> imply that what I stated could happen.
>
> Josh, no need to apologize. You simply tried to understand "git
> describe". The mere fact that a Git long time contributor (J6t) and an
> occasional contributor (I) are discussing "git describe"'s behaviour
> tells you that it can't be that easy ;)
>
> The man page says "most recent tag", and that is true, but with a
> definition of "most recent" that you wouldn't expect. The description
> there under "Search Strategy" is wrong, and has been at least since
> 80dbae03. I'll try to come up with a better explanation fit for the man
> page, possibly after writing some more tests.
>
> The intended behaviour is explained really well in Shawn's commit
> message for 80dbae03. And if you look at the algorithm you see that the
> order of the parents (as stored in a merge commit), in particular
> first-parent relationship plays no role at all. The algo takes all
> parents and inserts them in date order into a list to be looped over
> afterwards.
>
> The more I understand the algo the more I realize that --first-parent is
> useful and completely different, and that I can optimize more in my patch.
>
> Cheers
> Michael
>