Subject: Re: What's cooking in git.git (topics)

From: Andreas Ericsson <[email-masked]>
Date: Thu, 11 Jan 2007 10:20:43 +0100

Shawn O. Pearce wrote:
> Nicolas Pitre <[email-masked]> 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                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231