Re: [BUG] "git describe --match" performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 31, 2024 at 09:25:22AM -0700, Josh Poimboeuf wrote:

> But my real development repo, which has many branches and remotes plus
> the historical git repo grafted, still takes 10+ seconds.

If grafts are present, the use of the commit-graph is disabled, because
the point of the commit-graph is precomputing and caching various
properties of commits. Which, absent grafting, are immutable.

I think we talked long ago about computing commit-graphs over the
grafted state, and then using those graphs as long as the graft state
remained the same. But I don't think we ever implemented anything.

Another possibility (that I don't recall we've ever discussed) is
partially using commit graphs. Some commit properties, like generation
numbers, depend on other commits. So a graft at the bottom of history is
going to rewrite the generations for all of the descendants. But we
could still use the graph information to load the parents and trees of
all of the non-grafted commits. Those are still valid even in a grafted
situation, and that's what's providing most of the speed up in this case
(without it, we're literally zlib inflating each commit we traverse in
order to find its parents, versus an integer lookup via the
commit-graph).

That might not be _too_ hard to implement. In theory, anyway. :)

> Note the commit it finishes at is from almost 20 years ago (I have
> historical Linux git history grafted in which goes back to 1991):
> 
> commit d8470b7c13e11c18cf14a7e3180f0b00e715e4f0
> Author: Karsten Keil <kkeil@xxxxxxx>
> Date:   Thu Apr 21 08:30:30 2005 -0700
> 
>     [PATCH] fix for ISDN ippp filtering
> 
>     We do not longer use DLT_LINUX_SLL for activ/pass filters but
>     DLT_PPP_WITHDIRECTION witch need 1 as outbound flag.
> 
>     Signed-off-by: Karsten Keil <kkeil@xxxxxxx>
>     Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
> 
> 
> Presumably only one candidate matches the "v6.12-rc5" glob (which is an
> exact string, not a wildcard) so it tries to find 9 more but never finds
> any?
> 
> Since it's not a wildcard pattern, I would expect it to stop immediately
> when it reaches the exact match.

Yeah, I think this is just the same issue we've been discussing.

-Peff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux