Nicolas Pitre <nico@xxxxxxx> wrote: > On Wed, 10 Jan 2007, Junio C Hamano wrote: > > * sp/describe (Wed Jan 10 06:39:47 2007 -0500) 1 commit > > - Chose better tag names in git-describe after merges. > > > > Slowing it down by 4x is very unfortunate. I think there is a > > better way to walk the ancestry than doing one at a time to > > count the commits, but I did not have enough time to look at > > this today. > > However git-describe is certainly not a frequent and speed critical > operation, and > even if it cannot be sped up then waiting 300 ms more won't really > affect one's workflow that badly. My thoughts exactly. I spent a few hours trying to determine an algorithm that produced the right answer and did not require generating the revlist between the tag and the requested commit for every possibly matching tag. I did not come up with one. If someone else does it would obviously be a welcome replacement to my own patch. :-) There is almost no additional penalty for a simple strand of pearls with the tag placed along that strand; only one possible tag will be found. But my code does an unnecessary revision list in this case. Where we really get hit is the large number of possible tags. The master branch is turning up 14 tags, some dating back to v1.4.1-rc1. I do try to abort the revision list as soon as one of those tags cannot give me a better selection than the one I have currently, but I still had to generate a revision list to reach that point. -- Shawn. - 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