From: Andreas Ericsson Date: Thu, 11 Jan 2007 09:20:43 GMT Subject: Re: What's cooking in git.git (topics) Message-ID: <45A6016B.4030800@op5.se> In-Reply-To: <20070111080035.GA28222@spearce.org> Shawn O. Pearce wrote: > Nicolas Pitre 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. > It could be worth skipping tags more than 6 months older than current branch-head. That would, at least for the git case, cut the number of tags down by a considerable amount. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231