Re: Slow fetches of tags

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, May 24, 2006 at 09:45:29AM -0700, Linus Torvalds wrote:

> So this is a tree where you already _have_ most of the tags, no?

Yes, git did end up only fetching v2.6.16.18 as the single tag.

> Can you add a printout to show what the "taglist" is for you in 
> git-fetch.sh (just before the thing that does that
> 
> 	fetch_main "$taglist"
> 
> thing?). It _should_ have pruned out all the tags you already have.

Right, it's just "refs/tags/v2.6.16.18:refs/tags/v2.6.16.18".

> Or is it just the "git-ls-remote" that takes forever?

git-ls-remote git://www.kernel.org/pub/scm/linux/kernel/git/stable/\
linux-2.6.16.y takes about 1.5s.

> (Or, if you run 
> "top", is there something that is an obviously heavy operation on the 
> client side?)

git-fetch-pack was burning some 6min CPU.  Nothing else even even shows
up on the "top" radar.

Another funny thing I noticed in top is that the git-fetch-pack arguments
got overwritten:

$ cat /proc/1702/cmdline | tr '\0' ' '
git-fetch-pack --thin git //www.kernel.org pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git  efs/heads/master  efs/tags/v2.6.16.18

Guess that doesn't matter.  Anyway, so I ran strace on this git-fetch-pack
invocation:

[...]
munmap(0xb7fe5000, 229)                 = 0
getdents(5, /* 0 entries */, 4096)      = 0
close(5)                                = 0
getdents(4, /* 0 entries */, 4096)      = 0
close(4)                                = 0
write(3, "0046want 9b549d8e1e2f16cffbb414a"..., 70) = 70
write(3, "0000", 4)                     = 4
write(3, "0032have 0bcf7932d0ea742e765a40b"..., 50) = 50
write(3, "0032have 54e938a80873e85f9c02ab4"..., 50) = 50
write(3, "0032have 2d0a9369c540519bab8018e"..., 50) = 50
write(3, "0032have bf3060065ef9f0a8274fc32"..., 50) = 50
write(3, "0032have 27602bd8de8456ac619b77c"..., 50) = 50
[... another 42,000+ similar lines chopped off ...]

9b549d8e1e2f16cffbb414a is Chris Wright's tag for v2.6.16.18.  So far,
as expected.

And this is where things are getting interesting:

$ git-name-rev 0bcf7932d0ea742e765a40b
0bcf7932d0ea742e765a40b master
$ git-name-rev 54e938a80873e85f9c02ab4
54e938a80873e85f9c02ab4 34k-2.6.16.18
$ git-name-rev 2d0a9369c540519bab8018e
2d0a9369c540519bab8018e 34k-2.6.16.18~1
$ git-name-rev bf3060065ef9f0a8274fc32
bf3060065ef9f0a8274fc32 34k-2.6.16.18~2
$ git-name-rev 27602bd8de8456ac619b77c
27602bd8de8456ac619b77c 34k-2.6.16.18~3

It's sending every object back to the start of history ...

  Ralf