Re: Slow fetches of tags

From: Ralf Baechle <ralf@linux-mips.org>
Date: May 24, 2006, 18:08 UTC
Message-ID: <20060524180813.GA32519@linux-mips.org>
In-Reply-To: <Pine.LNX.4.64.0605240931480.5623@g5.osdl.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.

Show 6 quoted lines

> 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