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. On Tue, Sep 21, 2010 at 11:26 AM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > 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 > -- 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