On Sun, 10 Feb 2008, Junio C Hamano wrote: > Len Brown <lenb@xxxxxxxxxx> writes: > > > A couple of hours ago I pulled my reference copy of Linux tree, > > which brought the tip here: > > > > commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1 > > Merge: 58a14ee... 30ddb15... > > Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxxxxxxxx> > > Date: Sun Feb 10 12:03:57 2008 -0800 > > > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 > > > > Then, 10 minutes ago I did a pull to bring the head here: > > > > commit 19af35546de68c872dcb687613e0902a602cb20e > > Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxxxxxxxx> > > Date: Sun Feb 10 14:18:14 2008 -0800 > > > > Linux 2.6.25-rc1 > > > > But this second pull seems to have re-downloaded 172MB, > > when it should have only needed the last few commits. > > > > thanks, > > Thanks. This is very puzzling. > > > [lenb@d975xbx2 linus (master)]$ git pull > > remote: Counting objects: 447, done. > > remote: Compressing objects: 100% (39/39), done. > > remote: Total 328 (delta 291), reused 325 (delta 289) > > This part looks quite sane. > > $ git rev-list --objects ^7cf712d v2.6.25-rc1^0 | wc -l > 328 > > > Receiving objects: 100% (328/328), 60.81 KiB, done. > > Resolving deltas: 100% (291/291), completed with 97 local objects. > > and the number of received objects exactly match. > > > warning: no common commits > > This is however very unexpected. The sequence internally should > be doing the equivalent of: > > - fetch the objects to complete the branches we track > (i.e. what the above "rev-list" that fetches to complete the > commit pointed by the v2.6.25-rc1 tag based on your earlier > tip 7cf712d); > > - store the tip (19af355 = v2.6.25-rc1^0) to the tracking > branch; > > - run another "git fetch" to retrieve objects to complete the > v2.6.25-rc1 tag itself, based on our available refs (which > includes the commit 19af355). I wonder if the problem is that something isn't getting reinitialized for the second connection. It's not a separate invocation of fetch-pack, and I can't say for sure that it's sending the right info to the server when the statics in builtin-fetch-pack.c are left over from the earlier call. This would particularly explain the information that hitting ctrl-c and trying again fixes it. I don't really know the builtin-fetch-pack code all that well, but I'll see if I can reproduce the problem and if I can figure out anything obviously wrong. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
