On 13/04/12 10:29, Daniel Friesen wrote: I disagree, 18M vs 341M is quite noticeable. Only if you're cloning on the same filesystem. We're talking about a network operation here. You're not counting the bandwidth needs. Transfering the whole amount is probably the slowest operation, not the CPU time needed to traverse the tree.

On 14/04/12 08:42, Daniel Friesen wrote: $ time git clone file://mediawiki/core core-full Cloning into 'core-full'... remote: Counting objects: 356100, done. remote: Compressing objects: 100% (60989/60989), done. Receiving objects: 100% (356100/356100), 121.81 MiB | 12.30 MiB/s, done. remote: Total 356100 (delta 301263), reused 348780 (delta 294195) Resolving deltas: 100% (301263/301263), done. real 1m43.218s user 1m38.904s sys 0m3.693s $ time git clone --depth 1 file:///home/repos/git/mw/mediawiki/core core-shallow Cloning into 'core-shallow'... remote: Counting objects: 2670, done. remote: Compressing objects: 100% (2504/2504), done. remote: Total 2670 (delta 273), reused 1372 (delta 119) Receiving objects: 100% (2670/2670), 16.55 MiB | 4.30 MiB/s, done. Resolving deltas: 100% (273/273), done. real 0m7.022s user 0m7.216s sys 0m0.493s $ du -sh core-full/.git core-shallow/.git 132M core-full/.git 18M core-shallow/.git Using --depth 5 vs --depth 1 doesn't make much difference: 19M core-shallow5/.git Also counting the checkout adds a constant amount: $ du -sh core-full core-shallow core-shallow5 199M core-full 84M core-shallow 85M core-shallow5 I don't know why your depthed clone was so big. Could be related to https using the dumb protocol, but still, it's a difference too big. So I tried with your parameters: $ time git clone https://github.com/dantman/mediawiki-core.git a Cloning into 'a'... remote: Counting objects: 398899, done. remote: Compressing objects: 100% (52956/52956), done. remote: Total 398899 (delta 345088), reused 398821 (delta 345010) Receiving objects: 100% (398899/398899), 109.91 MiB | 164 KiB/s, done. Resolving deltas: 100% (345088/345088), done. real 7m54.988s user 1m5.466s sys 0m4.456s $ time git clone --depth 5 https://github.com/dantman/mediawiki-core.git b Cloning into 'b'... remote: Counting objects: 2705, done. remote: Compressing objects: 100% (2487/2487), done. remote: Total 2705 (delta 264), reused 1628 (delta 171) Receiving objects: 100% (2705/2705), 17.22 MiB | 294 KiB/s, done. Resolving deltas: 100% (264/264), done. real 1m6.691s user 0m1.603s sys 0m0.573s $ du -sh a b 191M a 88M b $ du -sh a/.git b/.git 122M a/.git 18M b/.git Note that the .git folder in the shallow case is just 18M and I only needed to download 17M from the net (why were them 48.25M for you?). For reference, the github clone was at 76dd5fe50aa8f3ed3f436ce737ab339f85e0c63e and mediawiki/core at 76881580cd9c30681aa65b228e0757c0515bbaa5 (288 commits more) when I performed these tests.

If you read my comments on that bug you will see I believe it is an upstream issue and is probably fixed in 2.3. -Chad On Apr 14, 2012 12:31 PM, "Thomas Gries" <mail(a)tgries.de> wrote:

Yes, but if you read the release notes for 2.3 you will see they've upgraded to jgit 1.1. I'd like to upgrade our gerrit install in a week or two. -Chad On Apr 15, 2012 3:34 AM, "Thomas Gries" <mail(a)tgries.de> wrote:

now filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=35949 *Bug 35949* <https://bugzilla.wikimedia.org/show_bug.cgi?id=35949> -Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500