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

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

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