Shawn O. Pearce wrote:
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.
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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