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

["Shawn O. Pearce" <spearce@spearce.org>]

Nicolas Pitre <nico@cam.org> 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.