On Thu, Oct 31, 2024 at 11:31:43AM -0400, Jeff King wrote:
> On Thu, Oct 31, 2024 at 08:10:00AM -0700, Josh Poimboeuf wrote:
>
> > > I think we'll build the commit graph file by default these days when you
> > > run "git gc". But we don't build it immediately after cloning. Perhaps
> > > we should change that.
> >
> > Hm... I actually ran "git gc" and it didn't seem to help at all.
>
> What version of Git are you running? I think gc enabled it by default in
> 31b1de6a09 (commit-graph: turn on commit-graph by default, 2019-08-13),
> which is v2.24.0.
>
> You could also try "git commit-graph write --reachable" and see if that
> improves things. If it doesn't, then maybe you have the reading side
> turned off explicitly for some reason? Try "git config core.commitgraph"
> to see if you have that set to "false".
Actually, I take that back. You're right, in the freshly cloned repo,
"git gc" did help ~10x:
$ git describe --match=v6.10-rc7
v6.10-rc7-1844-gc61e41121036
real 0m10.681s
user 0m9.442s
sys 0m0.507s
$ git gc
Enumerating objects: 10460179, done.
Counting objects: 100% (10460179/10460179), done.
Delta compression using up to 12 threads
Compressing objects: 100% (1886458/1886458), done.
Writing objects: 100% (10460179/10460179), done.
Total 10460179 (delta 8517403), reused 10460179 (delta 8517403), pack-reused 0 (from 0)
Expanding reachable commits in commit graph: 1310355, done.
Writing out commit graph in 5 passes: 100% (6551775/6551775), done.
$ time git describe --match=v6.10-rc7
v6.10-rc7-1844-gc61e41121036
real 0m1.173s
user 0m1.002s
sys 0m0.136s
But my real development repo, which has many branches and remotes plus
the historical git repo grafted, still takes 10+ seconds.
$ git --version
git version 2.47.0
$ git gc
Enumerating objects: 14656254, done.
Counting objects: 100% (12534942/12534942), done.
Delta compression using up to 12 threads
Compressing objects: 100% (1829918/1829918), done.
Writing objects: 100% (12534942/12534942), done.
Total 12534942 (delta 10652548), reused 12534853 (delta 10652487), pack-reused 0 (from 0)
Enumerating cruft objects: 6133, done.
Traversing cruft objects: 14736, done.
Counting objects: 100% (6133/6133), done.
Delta compression using up to 12 threads
Compressing objects: 100% (1179/1179), done.
Writing objects: 100% (6133/6133), done.
Total 6133 (delta 4876), reused 6117 (delta 4865), pack-reused 0 (from 0)
$ git commit-graph write --reachable
Expanding reachable commits in commit graph: 1941353, done.
Finding extra edges in commit graph: 100% (1941353/1941353), done.
Writing out commit graph in 5 passes: 100% (9706765/9706765), done.
$ git config core.commitgraph
$
$ git describe --match=v6.12-rc5 --debug
describe HEAD
No exact match on refs or tags, searching to describe
finished search at d8470b7c13e11c18cf14a7e3180f0b00e715e4f0
annotated 297 v6.12-rc5
traversed 1310258 commits
v6.12-rc5-297-ge7427640278f
real 0m11.626s
user 0m11.298s
sys 0m0.289s
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.
--
Josh
