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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html