From: Joshua Shrader Date: Tue, 21 Sep 2010 19:57:07 GMT Subject: Re: can git-describe learn first-parent behavior? Message-ID: In-Reply-To: <4C98CEA1.2050405@drmicha.warpmail.net> 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 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 > , "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 >