{"thread":{"id":"12019","subject":"warning: no common commits - slow pull","startedAt":"2008-02-11T01:07:38Z","lastAt":"2008-02-29T17:14:54Z","messageCount":35,"participants":["Len Brown","Junio C Hamano","Theodore Tso","Florian Weimer","Nix","Johannes Schindelin","Daniel Barkalow","Nicolas Pitre","Shawn O. Pearce","Jon Loeliger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68302","messageId":"200802102007.38838.lenb@kernel.org","threadId":"12019","inReplyTo":null,"subject":"warning: no common commits - slow pull","fromName":"Len Brown","fromEmail":"lenb@kernel.org","sentAt":"2008-02-11T01:07:38Z","receivedAt":"2008-02-11T01:07:38Z","isPatch":false,"sender":{"key":"lenb@kernel.org","avatar":null},"body":"A couple of hours ago I pulled my reference copy of Linux tree,\nwhich brought the tip here:\n\ncommit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\nMerge: 58a14ee... 30ddb15...\nAuthor: Linus Torvalds \nDate: Sun Feb 10 12:03:57 2008 -0800\n\n Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n\nThen, 10 minutes ago I did a pull to bring the head here:\n\ncommit 19af35546de68c872dcb687613e0902a602cb20e\nAuthor: Linus Torvalds \nDate: Sun Feb 10 14:18:14 2008 -0800\n\n Linux 2.6.25-rc1\n\nBut this second pull seems to have re-downloaded 172MB,\nwhen it should have only needed the last few commits.\n\nthanks,\n-Len\n\n\n[lenb@d975xbx2 linus (master)]$ git pull\nremote: Counting objects: 447, done.\nremote: Compressing objects: 100% (39/39), done.\nremote: Total 328 (delta 291), reused 325 (delta 289)\nReceiving objects: 100% (328/328), 60.81 KiB, done.\nResolving deltas: 100% (291/291), completed with 97 local objects.\nwarning: no common commits\nremote: Counting objects: 708151, done.\nremote: Compressing objects: 100% (124656/124656), done.\nremote: Total 708151 (delta 587427), reused 702559 (delta 582537)\nReceiving objects: 100% (708151/708151), 172.17 MiB | 1251 KiB/s, done.\nResolving deltas: 100% (587427/587427), done.\nFrom git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n * [new tag] v2.6.25-rc1 -> v2.6.25-rc1\nUpdating 7cf712d..19af355\nFast forward\n Makefile | 4 +-\n arch/arm/configs/omap_h2_1610_defconfig | 201 +++++---\n arch/arm/configs/omap_osk_5912_defconfig | 110 ++--\n arch/arm/configs/orion_defconfig | 93 ++--\n arch/arm/kernel/setup.c | 2 +-\n arch/arm/mach-at91/clock.c | 2 +-\n arch/arm/mach-davinci/clock.c | 4 +-\n arch/arm/mach-omap1/Makefile | 6 +-\n arch/arm/mach-omap1/board-ams-delta.c | 7 +-\n arch/arm/mach-omap1/board-fsample.c | 6 +-\n arch/arm/mach-omap1/board-generic.c | 24 +-\n arch/arm/mach-omap1/board-h2-mmc.c | 110 ++++\n arch/arm/mach-omap1/board-h2.c | 103 ++---\n arch/arm/mach-omap1/board-h3-mmc.c | 114 ++++\n arch/arm/mach-omap1/board-h3.c | 75 +--\n arch/arm/mach-omap1/board-innovator.c | 19 +-\n arch/arm/mach-omap1/board-nokia770.c | 3 +-\n arch/arm/mach-omap1/board-osk.c | 25 +-\n arch/arm/mach-omap1/board-palmte.c | 84 +--\n arch/arm/mach-omap1/board-palmtt.c | 15 +-\n arch/arm/mach-omap1/board-palmz71.c | 3 +-\n arch/arm/mach-omap1/board-perseus2.c | 8 +-\n arch/arm/mach-omap1/board-sx1-mmc.c | 124 +++++\n arch/arm/mach-omap1/board-sx1.c | 64 +--\n arch/arm/mach-omap1/board-voiceblue.c | 4 +-\n arch/arm/mach-omap1/clock.c | 7 +-\n arch/arm/mach-omap1/leds-osk.c | 4 +-\n arch/arm/mach-omap1/mailbox.c | 14 +-\n arch/arm/mach-omap1/pm.c | 27 +-\n arch/arm/mach-omap1/sleep.S | 161 ------\n arch/arm/mach-orion/addr-map.c | 14 +-\n arch/arm/mach-orion/common.c | 84 ++-\n arch/arm/mach-orion/common.h | 8 +\n arch/arm/mach-orion/db88f5281-setup.c | 4 +-\n arch/arm/mach-orion/dns323-setup.c | 8 +-\n arch/arm/mach-orion/kurobox_pro-setup.c | 17 +-\n arch/arm/mach-orion/pci.c | 10 +-\n arch/arm/mach-orion/rd88f5182-setup.c | 17 +-\n arch/arm/mach-orion/ts209-setup.c | 20 +-\n arch/arm/mach-pxa/pxa3xx.c | 10 +-\n arch/arm/plat-omap/Makefile | 1 +\n arch/arm/plat-omap/dma.c | 844 +++++++++++++++++++++++++++--\n arch/arm/plat-omap/dmtimer.c | 118 +++-\n arch/arm/plat-omap/gpio.c | 256 +++++++---\n arch/arm/plat-omap/i2c.c | 148 +++++\n arch/arm/plat-omap/mcbsp.c | 11 +\n arch/ia64/pci/pci.c | 25 +-\n arch/ia64/sn/pci/tioce_provider.c | 16 +-\n arch/x86/kernel/quirks.c | 2 +-\n arch/x86/pci/common.c | 25 +-\n arch/x86/pci/direct.c | 4 +-\n arch/x86/pci/fixup.c | 6 +-\n arch/x86/pci/legacy.c | 2 +-\n arch/x86/pci/mmconfig-shared.c | 41 +--\n arch/x86/pci/mmconfig_32.c | 20 +-\n arch/x86/pci/mmconfig_64.c | 18 +-\n arch/x86/pci/pci.h | 22 +-\n arch/x86/pci/visws.c | 3 -\n drivers/acpi/osl.c | 25 +-\n include/asm-arm/arch-omap/board-apollon.h | 2 +\n include/asm-arm/arch-omap/board-h2.h | 3 +\n include/asm-arm/arch-omap/board-h3.h | 2 +\n include/asm-arm/arch-omap/board-sx1.h | 8 +-\n include/asm-arm/arch-omap/common.h | 11 +\n include/asm-arm/arch-omap/cpu.h | 127 ++++-\n include/asm-arm/arch-omap/dma.h | 135 ++++--\n include/asm-arm/arch-omap/gpio.h | 4 +\n include/asm-arm/arch-omap/irqs.h | 2 +\n include/asm-arm/arch-omap/nand.h | 24 +\n include/asm-arm/arch-orion/debug-macro.S | 9 +-\n include/asm-arm/arch-orion/entry-macro.S | 4 +-\n include/asm-arm/arch-orion/hardware.h | 13 +-\n include/asm-arm/arch-orion/orion.h | 102 +++--\n include/asm-arm/arch-orion/uncompress.h | 14 +-\n include/asm-arm/arch-orion/vmalloc.h | 2 +-\n include/linux/pci.h | 16 +-\n 76 files changed, 2581 insertions(+), 1099 deletions(-)\n create mode 100644 arch/arm/mach-omap1/board-h2-mmc.c\n create mode 100644 arch/arm/mach-omap1/board-h3-mmc.c\n create mode 100644 arch/arm/mach-omap1/board-sx1-mmc.c\n create mode 100644 arch/arm/plat-omap/i2c.c\n create mode 100644 include/asm-arm/arch-omap/nand.h\n[lenb@d975xbx2 linus (master)]$ \n[lenb@d975xbx2 acpi (release)]$ git --version\ngit version 1.5.4.1.34.g94bf\n\n \n"},{"id":"68308","messageId":"7vd4r4clnb.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"200802102007.38838.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-11T01:44:08Z","receivedAt":"2008-02-11T01:44:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Len Brown writes:\n\n> A couple of hours ago I pulled my reference copy of Linux tree,\n> which brought the tip here:\n>\n> commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\n> Merge: 58a14ee... 30ddb15...\n> Author: Linus Torvalds \n> Date: Sun Feb 10 12:03:57 2008 -0800\n>\n> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n>\n> Then, 10 minutes ago I did a pull to bring the head here:\n>\n> commit 19af35546de68c872dcb687613e0902a602cb20e\n> Author: Linus Torvalds \n> Date: Sun Feb 10 14:18:14 2008 -0800\n>\n> Linux 2.6.25-rc1\n>\n> But this second pull seems to have re-downloaded 172MB,\n> when it should have only needed the last few commits.\n>\n> thanks,\n\nThanks. This is very puzzling.\n\n> [lenb@d975xbx2 linus (master)]$ git pull\n> remote: Counting objects: 447, done.\n> remote: Compressing objects: 100% (39/39), done.\n> remote: Total 328 (delta 291), reused 325 (delta 289)\n\nThis part looks quite sane.\n\n\t$ git rev-list --objects ^7cf712d v2.6.25-rc1^0 | wc -l\n\t328\n\n> Receiving objects: 100% (328/328), 60.81 KiB, done.\n> Resolving deltas: 100% (291/291), completed with 97 local objects.\n\nand the number of received objects exactly match.\n\n> warning: no common commits\n\nThis is however very unexpected. The sequence internally should\nbe doing the equivalent of:\n\n - fetch the objects to complete the branches we track\n (i.e. what the above \"rev-list\" that fetches to complete the\n commit pointed by the v2.6.25-rc1 tag based on your earlier\n tip 7cf712d);\n\n - store the tip (19af355 = v2.6.25-rc1^0) to the tracking\n branch;\n\n - run another \"git fetch\" to retrieve objects to complete the\n v2.6.25-rc1 tag itself, based on our available refs (which\n includes the commit 19af355).\n\nwhich should result in transferring only one object, which would\nsay something like:\n\n From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n 7cf712d..19af355 master -> linus\n remote: Counting objects: 1, done.\n remote: Total 1 (delta 0), reused 0 (delta 0)\n Unpacking objects: 100% (1/1), done.\n From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n * [new tag] v2.6.25-rc1 -> v2.6.25-rc1\n Updating 7cf712d..19af355\n\nWe would need a bit more digging to reproduce it, as I do not\nseem to be able to.\n"},{"id":"68309","messageId":"20080211015342.GA26205@mit.edu","threadId":"12019","inReplyTo":"200802102007.38838.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-02-11T01:53:42Z","receivedAt":"2008-02-11T01:53:42Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Feb 10, 2008 at 08:07:38PM -0500, Len Brown wrote:\n> A couple of hours ago I pulled my reference copy of Linux tree,\n> which brought the tip here:\n> \n> commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\n> Merge: 58a14ee... 30ddb15...\n> Author: Linus Torvalds \n> Date: Sun Feb 10 12:03:57 2008 -0800\n> \n> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n> \n> Then, 10 minutes ago I did a pull to bring the head here:\n> \n> commit 19af35546de68c872dcb687613e0902a602cb20e\n> Author: Linus Torvalds \n> Date: Sun Feb 10 14:18:14 2008 -0800\n> \n> Linux 2.6.25-rc1\n> \n> But this second pull seems to have re-downloaded 172MB,\n> when it should have only needed the last few commits.\n\nYeah, I have this problem very often when I push to the ext4 tree on\nmaster.kernel.org. Apparently the push/pull logic isn't smart about\nobjects are found via objects/info/alterntaes, so it will needlessly\ntransfer objects that it doesn't need to.\n\nWhat I do to deal with this problem is I'll manually log into\nmaster.kernel.org, and then use the command \"git-update-ref\nrefs/heads/origin 19af35546de68c872dcb687613e0902a602cb20e\", and then\ngo back and do the push/pull. Once there is a head which points to the\nlatest from Linus, then the push/pull logic is smart and will only\ndownload the few commitments that aren't in the local git repository\nand aren't found in a shared repository.\n\nAnnoying, but as long as you have shell access on the machine with the\ndestination repository, you can work around it.\n\n\t\t\t\t\t- Ted\n"},{"id":"68317","messageId":"200802102139.21645.lenb@kernel.org","threadId":"12019","inReplyTo":"20080211015342.GA26205@mit.edu","subject":"Re: warning: no common commits - slow pull","fromName":"Len Brown","fromEmail":"lenb@kernel.org","sentAt":"2008-02-11T02:39:21Z","receivedAt":"2008-02-11T02:39:21Z","isPatch":false,"sender":{"key":"lenb@kernel.org","avatar":null},"body":"On Sunday 10 February 2008 20:53, Theodore Tso wrote:\n> On Sun, Feb 10, 2008 at 08:07:38PM -0500, Len Brown wrote:\n> > A couple of hours ago I pulled my reference copy of Linux tree,\n> > which brought the tip here:\n> > \n> > commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\n> > Merge: 58a14ee... 30ddb15...\n> > Author: Linus Torvalds \n> > Date: Sun Feb 10 12:03:57 2008 -0800\n> > \n> > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n> > \n> > Then, 10 minutes ago I did a pull to bring the head here:\n> > \n> > commit 19af35546de68c872dcb687613e0902a602cb20e\n> > Author: Linus Torvalds \n> > Date: Sun Feb 10 14:18:14 2008 -0800\n> > \n> > Linux 2.6.25-rc1\n> > \n> > But this second pull seems to have re-downloaded 172MB,\n> > when it should have only needed the last few commits.\n> \n> Yeah, I have this problem very often when I push to the ext4 tree on\n> master.kernel.org. Apparently the push/pull logic isn't smart about\n> objects are found via objects/info/alterntaes, so it will needlessly\n> transfer objects that it doesn't need to.\n> \n> What I do to deal with this problem is I'll manually log into\n> master.kernel.org, and then use the command \"git-update-ref\n> refs/heads/origin 19af35546de68c872dcb687613e0902a602cb20e\", and then\n> go back and do the push/pull. Once there is a head which points to the\n> latest from Linus, then the push/pull logic is smart and will only\n> download the few commitments that aren't in the local git repository\n> and aren't found in a shared repository.\n> \n> Annoying, but as long as you have shell access on the machine with the\n> destination repository, you can work around it.\n\nyeah, I think I have see this with pushes onto kernel.org also,\nbut unlike Ted, I simply wait.\n\n-Len\n"},{"id":"68318","messageId":"7v4pcgcimw.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"20080211015342.GA26205@mit.edu","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-11T02:49:11Z","receivedAt":"2008-02-11T02:49:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> On Sun, Feb 10, 2008 at 08:07:38PM -0500, Len Brown wrote:\n>> A couple of hours ago I pulled my reference copy of Linux tree,\n>> which brought the tip here:\n>> \n>> commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\n>> Merge: 58a14ee... 30ddb15...\n>> Author: Linus Torvalds \n>> Date: Sun Feb 10 12:03:57 2008 -0800\n>> \n>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n>> \n>> Then, 10 minutes ago I did a pull to bring the head here:\n>> \n>> commit 19af35546de68c872dcb687613e0902a602cb20e\n>> Author: Linus Torvalds \n>> Date: Sun Feb 10 14:18:14 2008 -0800\n>> \n>> Linux 2.6.25-rc1\n>> \n>> But this second pull seems to have re-downloaded 172MB,\n>> when it should have only needed the last few commits.\n>\n> Yeah, I have this problem very often when I push to the ext4 tree on\n> master.kernel.org. Apparently the push/pull logic isn't smart about\n> objects are found via objects/info/alterntaes, so it will needlessly\n> transfer objects that it doesn't need to.\n\nI am aware of that \"push\" side thing (basically it does not do\nthe negotiation and unless you are always doing fast-forward\npushes it tends to send needless stuff), but I had an impression\nthat the issue Len is raising is different. Namely if you pull\nfrom Linus twice into the same tree you should never see that\n\"No common commits\".\n"},{"id":"68321","messageId":"20080211035501.GB26205@mit.edu","threadId":"12019","inReplyTo":"7v4pcgcimw.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-02-11T03:55:01Z","receivedAt":"2008-02-11T03:55:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Feb 10, 2008 at 06:49:11PM -0800, Junio C Hamano wrote:\n> I am aware of that \"push\" side thing (basically it does not do\n> the negotiation and unless you are always doing fast-forward\n> pushes it tends to send needless stuff), but I had an impression\n> that the issue Len is raising is different. Namely if you pull\n> from Linus twice into the same tree you should never see that\n> \"No common commits\".\n\nYeah, when I saw your response to him I realized that. I didn't\nnotice the \"No common commits\" message in his transcript, and assumed\nhe was referring to the problem I was describing.\n\nI wouldn't mind waiting myself, but it does result in uneeded objects\nin the destination repository, which I gather results in slightly more\ndisk load on the kernel.org servers since there's slightly less object\nsharing, and sometimes I'm pushing from behind a slow link (such as an\nEVDO wireless modem), and pushing the few megabytes worth of shared\nobjects can take a while. So I've just always gotten in the habit of\nshelling into master.kernel.org and manually doing the git-update-ref;\none of these days I'll get around to scripting it.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"68400","messageId":"877ihbcwu5.fsf@mid.deneb.enyo.de","threadId":"12019","inReplyTo":"200802102007.38838.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-02-11T15:54:42Z","receivedAt":"2008-02-11T15:54:42Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Len Brown:\n\n> But this second pull seems to have re-downloaded 172MB,\n> when it should have only needed the last few commits.\n\nI've got a linux-2.6 tree which is reasonable up to date, but which has\nbeen created by some acient GIT version. I see the same behavior from\ntime to time. The second pull, after I've canceled the first one,\nusually downloads just the expected data.\n"},{"id":"68446","messageId":"87ir0vxkkw.fsf@hades.wkstn.nix","threadId":"12019","inReplyTo":"877ihbcwu5.fsf@mid.deneb.enyo.de","subject":"Re: warning: no common commits - slow pull","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2008-02-11T21:13:51Z","receivedAt":"2008-02-11T21:13:51Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 11 Feb 2008, Florian Weimer spake thusly:\n\n> * Len Brown:\n>\n>> But this second pull seems to have re-downloaded 172MB,\n>> when it should have only needed the last few commits.\n>\n> I've got a linux-2.6 tree which is reasonable up to date, but which has\n> been created by some acient GIT version. I see the same behavior from\n> time to time. The second pull, after I've canceled the first one,\n> usually downloads just the expected data.\n\nI just saw it as well, doing a big update (most of the way from 2.6.23\nto current tip):\n\nloki 214 /usr/packages/linux/linux% git pull\nremote: Counting objects: 118487, done.\nremote: Compressing objects: 100% (22411/22411), done.\nremote: Total 102959 (delta 85610), reused 97521 (delta 80449)\nReceiving objects: 100% (102959/102959), 26.41 MiB | 70 KiB/s, done.\nResolving deltas: 100% (85610/85610), completed with 7493 local objects.\nwarning: no common commits\nremote: Counting objects: 708160, done.\nremote: Compressing objects: 100% (124705/124705), done.\nReceiving objects: 9% (70213/708160), 25.33 MiB | 70 KiB/s\n\nloki 215 /usr/packages/linux/linux% ls -l .git/objects/pack\ntotal 240224\n-r--r--r-- 1 compiler hackers 2651912 2008-02-11 20:44 pack-69c40f2970403946a75203cc393ecc2b1abf8aa3.idx\n-r--r--r-- 1 compiler hackers 69189104 2008-02-11 20:44 pack-69c40f2970403946a75203cc393ecc2b1abf8aa3.pack\n-r--r--r-- 1 compiler hackers 14719304 2007-12-02 16:01 pack-7eb87d068cee2214e4b0c5b6b571014654cbaaa4.idx\n-rw-r--r-- 1 compiler hackers 0 2007-12-06 14:45 pack-7eb87d068cee2214e4b0c5b6b571014654cbaaa4.keep\n-r--r--r-- 1 compiler hackers 157916633 2007-12-02 16:01 pack-7eb87d068cee2214e4b0c5b6b571014654cbaaa4.pack\n-r--r--r-- 1 compiler hackers 11744 2007-12-14 22:55 pack-993c8617968f3d44603663e4a2915ee260236f91.idx\n-r--r--r-- 1 compiler hackers 1004082 2007-12-14 22:55 pack-993c8617968f3d44603663e4a2915ee260236f91.pack\n\n\nOddly enough I then halted it: I have no desire to blow an extra 160Mb\nof space on duplicates of objects I've already got.\n\nPullng again promptly grabbed 102791 objects (i.e. prety much the same\nset again) as if the pack up there at the top of the directory listing\ndidn't even exist. (git-repack will happily clean up the duplicates for\nme, I'm sure.)\n\nThat time, it worked:\n\nloki 216 /usr/packages/linux/linux% git pull\nremote: Counting objects: 118319, done.\nremote: Compressing objects: 100% (22389/22389), done.\nremote: Total 102791 (delta 85463), reused 97353 (delta 80303)\nReceiving objects: 100% (102791/102791), 26.39 MiB | 91 KiB/s, done.\nResolving deltas: 100% (85463/85463), completed with 7494 local objects.\nFrom git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n * [new tag] v2.6.24 -> v2.6.24\n * [new tag] v2.6.24-rc1 -> v2.6.24-rc1\n * [new tag] v2.6.24-rc2 -> v2.6.24-rc2\n * [new tag] v2.6.24-rc3 -> v2.6.24-rc3\n * [new tag] v2.6.24-rc4 -> v2.6.24-rc4\n * [new tag] v2.6.24-rc5 -> v2.6.24-rc5\n * [new tag] v2.6.24-rc6 -> v2.6.24-rc6\n * [new tag] v2.6.24-rc7 -> v2.6.24-rc7\n * [new tag] v2.6.24-rc8 -> v2.6.24-rc8\n * [new tag] v2.6.25-rc1 -> v2.6.25-rc1\n[...]\n\nThis is with git version 1.5.4.25.g7f255-dirty. (only local changes are\nsome makefile tweaks).\n\nI've never seen this failure before with any earlier git version, but\nthat might just be coincidence.\n\n-- \n`The rest is a tale of post and counter-post.' --- Ian Rawlings\n describes USENET\n"},{"id":"68842","messageId":"200802151643.30232.lenb@kernel.org","threadId":"12019","inReplyTo":"20080211035501.GB26205@mit.edu","subject":"Re: warning: no common commits - slow pull","fromName":"Len Brown","fromEmail":"lenb@kernel.org","sentAt":"2008-02-15T21:43:30Z","receivedAt":"2008-02-15T21:43:30Z","isPatch":false,"sender":{"key":"lenb@kernel.org","avatar":null},"body":"it happened again.\n\nthis morning I pulled linus' tree up through \n4ee29f6a52158cea526b16a44ae38643946103ec\n\nthen during the day, linus declared \"rc2\".\n\nand now I pulled linus' tree again,\nwhich has a HEAD now of \n\n101142c37be8e5af9b847860219217e6b958c739\n\nand the pull sucked down 172 MB even though the uncompressed\ndiff between the two is 0.3 MB.\n\n-Len\n\n[lenb@d975xbx2 linus (master)]$ git pull\nremote: Counting objects: 649, done.\nremote: Compressing objects: 100% (106/106), done.\nremote: Total 513 (delta 417), reused 503 (delta 407)\nReceiving objects: 100% (513/513), 116.67 KiB, done.\nResolving deltas: 100% (417/417), completed with 103 local objects.\nwarning: no common commits\nremote: Counting objects: 710725, done.\nremote: Compressing objects: 100% (125738/125738), done.\nremote: Total 710725 (delta 589584), reused 704450 (delta 584029)\nReceiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\nResolving deltas: 100% (589584/589584), done.\nFrom git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\nUpdating 4ee29f6..101142c\nFast forward\n Makefile | 4 +-\n drivers/bluetooth/hci_ldisc.c | 1 +\n drivers/net/8139too.c | 2 +-\n drivers/net/Kconfig | 18 +\n drivers/net/Makefile | 3 +-\n drivers/net/cxgb3/l2t.c | 2 +-\n drivers/net/cxgb3/sge.c | 35 +-\n drivers/net/dm9000.c | 654 +++++---\n drivers/net/e1000/e1000_main.c | 18 +-\n drivers/net/forcedeth.c | 132 +-\n drivers/net/netconsole.c | 4 +-\n drivers/net/ni52.c | 1142 +++++++-------\n drivers/net/ni52.h | 158 +-\n drivers/net/pcnet32.c | 48 +-\n drivers/net/phy/fixed.c | 4 +-\n drivers/net/ps3_gelic_net.c | 1215 ++++++++------\n drivers/net/ps3_gelic_net.h | 415 ++++--\n drivers/net/ps3_gelic_wireless.c | 2753 ++++++++++++++++++++++++++++++++\n drivers/net/ps3_gelic_wireless.h | 329 ++++\n drivers/net/r6040.c | 233 ++--\n drivers/net/sis190.c | 3 +-\n drivers/s390/net/claw.h | 19 +-\n drivers/s390/net/lcs.c | 2 +-\n drivers/s390/net/lcs.h | 16 +-\n drivers/s390/net/netiucv.c | 29 +-\n fs/compat.c | 3 -\n fs/nfs/callback.c | 18 +-\n fs/nfs/dir.c | 8 +-\n fs/nfs/nfs4state.c | 4 +-\n fs/nfs/super.c | 4 +\n include/linux/dm9000.h | 2 +\n include/linux/netdevice.h | 8 +-\n include/net/ax25.h | 2 +\n include/net/ndisc.h | 1 -\n include/net/xfrm.h | 5 +-\n net/ax25/af_ax25.c | 12 +-\n net/ax25/ax25_dev.c | 2 +-\n net/ax25/ax25_ds_timer.c | 12 +-\n net/ax25/ax25_route.c | 28 +-\n net/ax25/ax25_timer.c | 60 +-\n net/core/dev.c | 4 +-\n net/core/neighbour.c | 12 +-\n net/core/rtnetlink.c | 36 +-\n net/core/skbuff.c | 3 +-\n net/ipv4/ah4.c | 2 +-\n net/ipv4/arp.c | 3 -\n net/ipv4/esp4.c | 5 +-\n net/ipv4/fib_trie.c | 99 +-\n net/ipv4/inet_hashtables.c | 3 -\n net/ipv4/ip_sockglue.c | 5 -\n net/ipv6/ah6.c | 2 +-\n net/ipv6/esp6.c | 5 +-\n net/ipv6/ip6_output.c | 6 +-\n net/ipv6/xfrm6_output.c | 2 +-\n net/key/af_key.c | 1 +\n net/netfilter/nf_conntrack_proto_tcp.c | 2 +-\n net/netfilter/xt_SECMARK.c | 2 +-\n net/netlabel/netlabel_domainhash.c | 6 +-\n net/netlabel/netlabel_unlabeled.c | 30 +-\n net/netlabel/netlabel_user.c | 3 +-\n net/netlink/genetlink.c | 6 +-\n net/socket.c | 3 +\n net/xfrm/Kconfig | 2 +-\n net/xfrm/xfrm_input.c | 4 +-\n net/xfrm/xfrm_output.c | 2 +-\n net/xfrm/xfrm_user.c | 1 +\n 66 files changed, 5686 insertions(+), 1971 deletions(-)\n create mode 100644 drivers/net/ps3_gelic_wireless.c\n create mode 100644 drivers/net/ps3_gelic_wireless.h\n[lenb@d975xbx2 linus (master)]$ \n[lenb@d975xbx2 linus (master)]$ git --version\ngit version 1.5.4.1.122.gaa8d\n \n"},{"id":"68937","messageId":"alpine.LSU.1.00.0802162115030.30505@racer.site","threadId":"12019","inReplyTo":"200802151643.30232.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-16T21:22:43Z","receivedAt":"2008-02-16T21:22:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Feb 2008, Len Brown wrote:\n\n> [lenb@d975xbx2 linus (master)]$ git pull\n> remote: Counting objects: 649, done.\n> remote: Compressing objects: 100% (106/106), done.\n> remote: Total 513 (delta 417), reused 503 (delta 407)\n> Receiving objects: 100% (513/513), 116.67 KiB, done.\n> Resolving deltas: 100% (417/417), completed with 103 local objects.\n> warning: no common commits\n> remote: Counting objects: 710725, done.\n> remote: Compressing objects: 100% (125738/125738), done.\n> remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> Resolving deltas: 100% (589584/589584), done.\n> >From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\n\nNow, this is funny. Apparently, everything worked fine for the master \nbranch (I suppose it is the master branch, anyway), but went wrong for \nfetching the _tag_.\n\n> [lenb@d975xbx2 linus (master)]$ git --version\n> git version 1.5.4.1.122.gaa8d\n\nI do not have that git version, but something is fishy there, so I guess \nit depends on your particular version.\n\nCiao,\nDscho\n"},{"id":"68948","messageId":"alpine.LNX.1.00.0802162239090.5496@iabervon.org","threadId":"12019","inReplyTo":"7vd4r4clnb.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-17T03:52:07Z","receivedAt":"2008-02-17T03:52:07Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 10 Feb 2008, Junio C Hamano wrote:\n\n> Len Brown writes:\n> \n> > A couple of hours ago I pulled my reference copy of Linux tree,\n> > which brought the tip here:\n> >\n> > commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1\n> > Merge: 58a14ee... 30ddb15...\n> > Author: Linus Torvalds \n> > Date: Sun Feb 10 12:03:57 2008 -0800\n> >\n> > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6\n> >\n> > Then, 10 minutes ago I did a pull to bring the head here:\n> >\n> > commit 19af35546de68c872dcb687613e0902a602cb20e\n> > Author: Linus Torvalds \n> > Date: Sun Feb 10 14:18:14 2008 -0800\n> >\n> > Linux 2.6.25-rc1\n> >\n> > But this second pull seems to have re-downloaded 172MB,\n> > when it should have only needed the last few commits.\n> >\n> > thanks,\n> \n> Thanks. This is very puzzling.\n> \n> > [lenb@d975xbx2 linus (master)]$ git pull\n> > remote: Counting objects: 447, done.\n> > remote: Compressing objects: 100% (39/39), done.\n> > remote: Total 328 (delta 291), reused 325 (delta 289)\n> \n> This part looks quite sane.\n> \n> \t$ git rev-list --objects ^7cf712d v2.6.25-rc1^0 | wc -l\n> \t328\n> \n> > Receiving objects: 100% (328/328), 60.81 KiB, done.\n> > Resolving deltas: 100% (291/291), completed with 97 local objects.\n> \n> and the number of received objects exactly match.\n> \n> > warning: no common commits\n> \n> This is however very unexpected. The sequence internally should\n> be doing the equivalent of:\n> \n> - fetch the objects to complete the branches we track\n> (i.e. what the above \"rev-list\" that fetches to complete the\n> commit pointed by the v2.6.25-rc1 tag based on your earlier\n> tip 7cf712d);\n> \n> - store the tip (19af355 = v2.6.25-rc1^0) to the tracking\n> branch;\n> \n> - run another \"git fetch\" to retrieve objects to complete the\n> v2.6.25-rc1 tag itself, based on our available refs (which\n> includes the commit 19af355).\n\nI wonder if the problem is that something isn't getting reinitialized for \nthe second connection. It's not a separate invocation of fetch-pack, and I \ncan't say for sure that it's sending the right info to the server when the \nstatics in builtin-fetch-pack.c are left over from the earlier call. This \nwould particularly explain the information that hitting ctrl-c and trying \nagain fixes it.\n\nI don't really know the builtin-fetch-pack code all that well, but I'll \nsee if I can reproduce the problem and if I can figure out anything \nobviously wrong.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"68992","messageId":"alpine.LSU.1.00.0802171449230.30505@racer.site","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802162239090.5496@iabervon.org","subject":"Re: warning: no common commits - slow pull","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-17T14:57:15Z","receivedAt":"2008-02-17T14:57:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 16 Feb 2008, Daniel Barkalow wrote:\n\n> I wonder if the problem is that something isn't getting reinitialized \n> for the second connection. It's not a separate invocation of fetch-pack, \n> and I can't say for sure that it's sending the right info to the server \n> when the statics in builtin-fetch-pack.c are left over from the earlier \n> call. This would particularly explain the information that hitting \n> ctrl-c and trying again fixes it.\n\nOh, that should be it! After all, the code in get_rev() in \nbuiltin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.\n\nSo I guess you'd need to set something like\n\n\tstruct commit_list *rev_list_orig;\n\t...\n\trev_list_orig = rev_list;\n\nbefore\n\n while ((sha1 = get_rev())) {\n\nin the function find_common(), and then, after the while() loop, do \nsomething like\n\n\twhile (rev_list_orig) {\n\t\tclear_commit_marks(rev_list->item,\n\t\t\tCOMPLETE | COMMON | COMMON_REF | SEEN | POPPED);\n\t\trev_list_orig = rev_list_orig->next;\n\t}\n\npossibly free()ing the rev_lists in the process.\n\nCiao,\nDscho\n"},{"id":"68998","messageId":"alpine.LNX.1.00.0802171236560.5496@iabervon.org","threadId":"12019","inReplyTo":"alpine.LSU.1.00.0802171449230.30505@racer.site","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-17T17:46:03Z","receivedAt":"2008-02-17T17:46:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Feb 2008, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sat, 16 Feb 2008, Daniel Barkalow wrote:\n> \n> > I wonder if the problem is that something isn't getting reinitialized \n> > for the second connection. It's not a separate invocation of fetch-pack, \n> > and I can't say for sure that it's sending the right info to the server \n> > when the statics in builtin-fetch-pack.c are left over from the earlier \n> > call. This would particularly explain the information that hitting \n> > ctrl-c and trying again fixes it.\n> \n> Oh, that should be it! After all, the code in get_rev() in \n> builtin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.\n> \n> So I guess you'd need to set something like\n> \n> \tstruct commit_list *rev_list_orig;\n> \t...\n> \trev_list_orig = rev_list;\n> \n> before\n> \n> while ((sha1 = get_rev())) {\n> \n> in the function find_common(), and then, after the while() loop, do \n> something like\n> \n> \twhile (rev_list_orig) {\n> \t\tclear_commit_marks(rev_list->item,\n> \t\t\tCOMPLETE | COMMON | COMMON_REF | SEEN | POPPED);\n> \t\trev_list_orig = rev_list_orig->next;\n> \t}\n> \n> possibly free()ing the rev_lists in the process.\n\nWhat's currently confusing me, which is probably why I haven't been able \nto reproduce the problem, is how we don't have the newly-received commits \nas still interesting. Clearly there's some way to end up with them \neither not being applicable or being already marked, but I'm not seeing \nit.\n\n(There's a good change that we could fix the problem with your loop, but \nI'd like to have a test case to make sure it's fixed and stays fixed)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"69004","messageId":"7vhcg71n9u.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"alpine.LSU.1.00.0802171449230.30505@racer.site","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-17T17:54:53Z","receivedAt":"2008-02-17T17:54:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 16 Feb 2008, Daniel Barkalow wrote:\n>\n>> I wonder if the problem is that something isn't getting reinitialized \n>> for the second connection. It's not a separate invocation of fetch-pack, \n>> and I can't say for sure that it's sending the right info to the server \n>> when the statics in builtin-fetch-pack.c are left over from the earlier \n>> call. This would particularly explain the information that hitting \n>> ctrl-c and trying again fixes it.\n>\n> Oh, that should be it! After all, the code in get_rev() in \n> builtin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.\n\nI seem to be slow today, but how does that explain that the\nproblem is reported only by Len so far?\n"},{"id":"69027","messageId":"alpine.LSU.1.00.0802171925330.30505@racer.site","threadId":"12019","inReplyTo":"7vhcg71n9u.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-17T19:27:16Z","receivedAt":"2008-02-17T19:27:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 17 Feb 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 16 Feb 2008, Daniel Barkalow wrote:\n> >\n> >> I wonder if the problem is that something isn't getting reinitialized \n> >> for the second connection. It's not a separate invocation of \n> >> fetch-pack, and I can't say for sure that it's sending the right info \n> >> to the server when the statics in builtin-fetch-pack.c are left over \n> >> from the earlier call. This would particularly explain the \n> >> information that hitting ctrl-c and trying again fixes it.\n> >\n> > Oh, that should be it! After all, the code in get_rev() in \n> > builtin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.\n> \n> I seem to be slow today, but how does that explain that the problem is \n> reported only by Len so far?\n\nHmm. The code I was referencing is only in \"next\" so far, right? And \nAFAICT it only occurs when you are fetching something which autofetches \ntags, right?\n\nBut thinking about this again: do we reuse the connection also for \nautomatic tag fetching? If not, my whole reasoning is wrong.\n\nCiao,\nDscho\n"},{"id":"69037","messageId":"alpine.LNX.1.00.0802171437460.5816@iabervon.org","threadId":"12019","inReplyTo":"alpine.LSU.1.00.0802171925330.30505@racer.site","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-17T20:41:49Z","receivedAt":"2008-02-17T20:41:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Feb 2008, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 17 Feb 2008, Junio C Hamano wrote:\n> \n> > Johannes Schindelin writes:\n> > \n> > > On Sat, 16 Feb 2008, Daniel Barkalow wrote:\n> > >\n> > >> I wonder if the problem is that something isn't getting reinitialized \n> > >> for the second connection. It's not a separate invocation of \n> > >> fetch-pack, and I can't say for sure that it's sending the right info \n> > >> to the server when the statics in builtin-fetch-pack.c are left over \n> > >> from the earlier call. This would particularly explain the \n> > >> information that hitting ctrl-c and trying again fixes it.\n> > >\n> > > Oh, that should be it! After all, the code in get_rev() in \n> > > builtin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.\n> > \n> > I seem to be slow today, but how does that explain that the problem is \n> > reported only by Len so far?\n> \n> Hmm. The code I was referencing is only in \"next\" so far, right? And \n> AFAICT it only occurs when you are fetching something which autofetches \n> tags, right?\n\nI think the code you referenced is quite old; the new thing is having it \ncalled twice in the same process, and that's also in \"master\" along with \nbuiltin-fetch, I think.\n\n> But thinking about this again: do we reuse the connection also for \n> automatic tag fetching? If not, my whole reasoning is wrong.\n\nNo, the way the protocol works, you can't request more stuff after you've \nreceived stuff on a connection, so we have to start a second one for that \ncase.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"69938","messageId":"87ablod7ed.fsf@mid.deneb.enyo.de","threadId":"12019","inReplyTo":"200802151643.30232.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-02-25T21:59:38Z","receivedAt":"2008-02-25T21:59:38Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Len Brown:\n\n> [lenb@d975xbx2 linus (master)]$ git pull\n> remote: Counting objects: 649, done.\n> remote: Compressing objects: 100% (106/106), done.\n> remote: Total 513 (delta 417), reused 503 (delta 407)\n> Receiving objects: 100% (513/513), 116.67 KiB, done.\n> Resolving deltas: 100% (417/417), completed with 103 local objects.\n> warning: no common commits\n> remote: Counting objects: 710725, done.\n> remote: Compressing objects: 100% (125738/125738), done.\n> remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> Resolving deltas: 100% (589584/589584), done.\n>>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n\nSame here, but on a slow DSL line, so I had to hit ^C:\n\nfw@deneb:~/src/linux/linux-2.6$ git pull\nremote: Counting objects: 94176, done.\nremote: Compressing objects: 100% (17486/17486), done.\nremote: Total 83287 (delta 70429), reused 78218 (delta 65712)\nReceiving objects: 100% (83287/83287), 18.66 MiB | 478 KiB/s, done.\nResolving deltas: 100% (70429/70429), completed with 7457 local objects.\nwarning: no common commits\nremote: Counting objects: 53267\n^C\n\nThis is Debian's 1:1.5.4.2-2 GIT version.\n"},{"id":"69947","messageId":"alpine.LNX.1.00.0802251826380.19024@iabervon.org","threadId":"12019","inReplyTo":"87ablod7ed.fsf@mid.deneb.enyo.de","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-25T23:32:06Z","receivedAt":"2008-02-25T23:32:06Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 25 Feb 2008, Florian Weimer wrote:\n\n> * Len Brown:\n> \n> > [lenb@d975xbx2 linus (master)]$ git pull\n> > remote: Counting objects: 649, done.\n> > remote: Compressing objects: 100% (106/106), done.\n> > remote: Total 513 (delta 417), reused 503 (delta 407)\n> > Receiving objects: 100% (513/513), 116.67 KiB, done.\n> > Resolving deltas: 100% (417/417), completed with 103 local objects.\n> > warning: no common commits\n> > remote: Counting objects: 710725, done.\n> > remote: Compressing objects: 100% (125738/125738), done.\n> > remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> > Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> > Resolving deltas: 100% (589584/589584), done.\n> >>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> \n> Same here, but on a slow DSL line, so I had to hit ^C:\n> \n> fw@deneb:~/src/linux/linux-2.6$ git pull\n> remote: Counting objects: 94176, done.\n> remote: Compressing objects: 100% (17486/17486), done.\n> remote: Total 83287 (delta 70429), reused 78218 (delta 65712)\n> Receiving objects: 100% (83287/83287), 18.66 MiB | 478 KiB/s, done.\n> Resolving deltas: 100% (70429/70429), completed with 7457 local objects.\n> warning: no common commits\n> remote: Counting objects: 53267\n> ^C\n\nCan you try making backups before pulling and see if you can get a \nreproducable case? I haven't been able to arrange to have it happen to me, \nand once it happens, it's changed the state of the repository such that it \nwon't happen again immediately. I found something suspicious at some \npoint, and suggested a possible fix, but it's impossible to tell if it's \nactually resolved without a test case.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70021","messageId":"200802261438.17014.lenb@kernel.org","threadId":"12019","inReplyTo":"200802151643.30232.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Len Brown","fromEmail":"lenb@kernel.org","sentAt":"2008-02-26T19:38:16Z","receivedAt":"2008-02-26T19:38:16Z","isPatch":false,"sender":{"key":"lenb@kernel.org","avatar":null},"body":"On Friday 15 February 2008, Len Brown wrote:\n> it happened again.\n> \n> this morning I pulled linus' tree up through \n> 4ee29f6a52158cea526b16a44ae38643946103ec\n> \n> then during the day, linus declared \"rc2\".\n> \n> and now I pulled linus' tree again,\n> which has a HEAD now of \n> \n> 101142c37be8e5af9b847860219217e6b958c739\n> \n> and the pull sucked down 172 MB even though the uncompressed\n> diff between the two is 0.3 MB.\n> \n> -Len\n> \n> [lenb@d975xbx2 linus (master)]$ git pull\n> remote: Counting objects: 649, done.\n> remote: Compressing objects: 100% (106/106), done.\n> remote: Total 513 (delta 417), reused 503 (delta 407)\n> Receiving objects: 100% (513/513), 116.67 KiB, done.\n> Resolving deltas: 100% (417/417), completed with 103 local objects.\n> warning: no common commits\n> remote: Counting objects: 710725, done.\n> remote: Compressing objects: 100% (125738/125738), done.\n> remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> Resolving deltas: 100% (589584/589584), done.\n> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\n> Updating 4ee29f6..101142c\n> Fast forward\n> Makefile | 4 +-\n...\n> [lenb@d975xbx2 linus (master)]$ \n> [lenb@d975xbx2 linus (master)]$ git --version\n> git version 1.5.4.1.122.gaa8d\n\nIt still happens with latest git. (linus has declared -rc3 this time)\nunfortunately for me, i'm not on broadband this time so it is extremely painful --\nto the point that i simply can't update this tree until i get home.\n\nI started at 4fa2b1cde0e3797549f711ce9e51c395b3d6d2a7\nand Linus' tree is at 7704a8b6fc4a8f51599eb2af4dcf1e2ac9c7e576\n\nThe diff between these commits is about 100KB uncompressed, but it seems\nthat I'm pulling down 175MB again...\n\nremote: Counting objects: 661, done.\nremote: Compressing objects: 100% (139/139), done.\nremote: Total 501 (delta 411), reused 443 (delta 362)\nReceiving objects: 100% (501/501), 73.89 KiB | 11 KiB/s, done.\nResolving deltas: 100% (411/411), completed with 101 local objects.\nwarning: no common commits\nremote: Counting objects: 714841, done.\nremote: Compressing objects: 100% (127590/127590), done.\nReceiving objects: 1% (11116/714841), 3.96 MiB | 5 KiB/s\n\n[lenb@t61 ~]$ git --version\ngit version 1.5.4.3.230.g2db511\n"},{"id":"70028","messageId":"alpine.LFD.1.00.0802261546030.3167@xanadu.home","threadId":"12019","inReplyTo":"200802261438.17014.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-26T20:47:28Z","receivedAt":"2008-02-26T20:47:28Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 26 Feb 2008, Len Brown wrote:\n\n> On Friday 15 February 2008, Len Brown wrote:\n> > it happened again.\n> > \n> > this morning I pulled linus' tree up through \n> > 4ee29f6a52158cea526b16a44ae38643946103ec\n> > \n> > then during the day, linus declared \"rc2\".\n> > \n> > and now I pulled linus' tree again,\n> > which has a HEAD now of \n> > \n> > 101142c37be8e5af9b847860219217e6b958c739\n> > \n> > and the pull sucked down 172 MB even though the uncompressed\n> > diff between the two is 0.3 MB.\n> > \n> > -Len\n> > \n> > [lenb@d975xbx2 linus (master)]$ git pull\n> > remote: Counting objects: 649, done.\n> > remote: Compressing objects: 100% (106/106), done.\n> > remote: Total 513 (delta 417), reused 503 (delta 407)\n> > Receiving objects: 100% (513/513), 116.67 KiB, done.\n> > Resolving deltas: 100% (417/417), completed with 103 local objects.\n> > warning: no common commits\n> > remote: Counting objects: 710725, done.\n> > remote: Compressing objects: 100% (125738/125738), done.\n> > remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> > Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> > Resolving deltas: 100% (589584/589584), done.\n> > From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> > * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\n> > Updating 4ee29f6..101142c\n> > Fast forward\n> > Makefile | 4 +-\n> ...\n> > [lenb@d975xbx2 linus (master)]$ \n> > [lenb@d975xbx2 linus (master)]$ git --version\n> > git version 1.5.4.1.122.gaa8d\n> \n> It still happens with latest git. (linus has declared -rc3 this time)\n\nSo it happens everytime a new tag is fetched.\n\n> unfortunately for me, i'm not on broadband this time so it is extremely painful --\n> to the point that i simply can't update this tree until i get home.\n\nWhat happens if you restart the pull after interrupting the first \nattempt?\n\n\nNicolas\n"},{"id":"70048","messageId":"alpine.LNX.1.00.0802261832550.19665@iabervon.org","threadId":"12019","inReplyTo":"200802261438.17014.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-26T23:45:55Z","receivedAt":"2008-02-26T23:45:55Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 26 Feb 2008, Len Brown wrote:\n\n> On Friday 15 February 2008, Len Brown wrote:\n> > it happened again.\n> > \n> > this morning I pulled linus' tree up through \n> > 4ee29f6a52158cea526b16a44ae38643946103ec\n> > \n> > then during the day, linus declared \"rc2\".\n> > \n> > and now I pulled linus' tree again,\n> > which has a HEAD now of \n> > \n> > 101142c37be8e5af9b847860219217e6b958c739\n> > \n> > and the pull sucked down 172 MB even though the uncompressed\n> > diff between the two is 0.3 MB.\n> > \n> > -Len\n> > \n> > [lenb@d975xbx2 linus (master)]$ git pull\n> > remote: Counting objects: 649, done.\n> > remote: Compressing objects: 100% (106/106), done.\n> > remote: Total 513 (delta 417), reused 503 (delta 407)\n> > Receiving objects: 100% (513/513), 116.67 KiB, done.\n> > Resolving deltas: 100% (417/417), completed with 103 local objects.\n> > warning: no common commits\n> > remote: Counting objects: 710725, done.\n> > remote: Compressing objects: 100% (125738/125738), done.\n> > remote: Total 710725 (delta 589584), reused 704450 (delta 584029)\n> > Receiving objects: 100% (710725/710725), 172.71 MiB | 1073 KiB/s, done.\n> > Resolving deltas: 100% (589584/589584), done.\n> > From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n> > * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\n> > Updating 4ee29f6..101142c\n> > Fast forward\n> > Makefile | 4 +-\n> ...\n> > [lenb@d975xbx2 linus (master)]$ \n> > [lenb@d975xbx2 linus (master)]$ git --version\n> > git version 1.5.4.1.122.gaa8d\n> \n> It still happens with latest git. (linus has declared -rc3 this time)\n> unfortunately for me, i'm not on broadband this time so it is extremely painful --\n> to the point that i simply can't update this tree until i get home.\n\nThe workaround, so far as I know, is to hit ^C and do it again; the second \ntime it will fetch 1 object (the actual tag) instead of 700000. If that's \nnot the case, I'm even more confused about what's going on. And if you \nnotice Linux tagging something before you pull, it would be great if you \ncould capture the contents of .git/refs/ before you pull and send it to me \nif it does this.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70057","messageId":"7vir0byoc2.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"200802261438.17014.lenb@kernel.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-27T05:12:45Z","receivedAt":"2008-02-27T05:12:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Len Brown writes:\n\n>> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n>> * [new tag] v2.6.25-rc2 -> v2.6.25-rc2\n>> Updating 4ee29f6..101142c\n>> Fast forward\n>> Makefile | 4 +-\n> ...\n>> [lenb@d975xbx2 linus (master)]$ \n>> [lenb@d975xbx2 linus (master)]$ git --version\n>> git version 1.5.4.1.122.gaa8d\n>\n> It still happens with latest git. (linus has declared -rc3 this time)\n\nThat's because nobody has touched anything in this area since your\nlast report.\n\nBut I now have a theory.\n\nNext time this happens, could you run ls-remote for all four git\nservers and compare them?\n\n $ LINUS=kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n $ for i in 1 2 3 4; do git ls-remote git://git$i.$LINUS >git$i.txt; done\n\nIf my theory is correct, a workaround would be not to fetch from\ngit://git.kernel.org/ but from git://git$i.kernel.org/ for some value\nof $i.\n\nNow to the theory part.\n\nSuppose the ancestry is like this:\n\n o (rc2) o (rc3)\n / /\n ---A---o---o---o---o---B---o---o---o---C\n\nAnd the event sequence is:\n\n (0) You are in sync with rc2 (have commits up to \"A\" and tag\n rc2);\n\n (1) Linus builds up to \"B\", tags rc3, pushes out to the master;\n\n (2) git1 and git2 mirror that history;\n\n (3) Linus builds up to \"C\", pushes out to the master;\n\n (4) git1 gets \"C\" but git2 mirror lags behind;\n\n (5) You fetch, which happens to first go to git1; you get \"C\"\n and learn that rc3 points at \"B\" that is locally reachable,\n but you do not have rc3 tag itself yet. So git-fetch\n auto-follows (i.e. asks for \"rc3\" tag);\n\n (6) However, that goes over a separate connection, and you\n happen to hit git2, which does have \"B\" and rc3, but it\n does not have \"C\" yet.\n\n (7) You tell the other end \"Hey, I have C\", which git2 does not\n understand, because it hasn't seen the commit through the\n mirroring system yet.\n\nNow, even if we are in the above situation, things _ought_ to work\n(and I strongly suspect that the scripted git-fetch did work\ncorrectly). git2 would say \"You have \"C\"? I dunno that one, but keep\ntalking\", and you will keep sending \"I have this, this, this,...\",\nwalking the ancestry chain down from C. When you say \"I also have B\",\nit would say \"Aha, Ok, I heard enough to tell that rc3 tag is the only\nthing I need to send to you\".\n\nHowever, if the current version of git-fetch has a bug in the\nnegotiation code when it auto-follows tags, that could throw this\nconversation to compute what's common way off, and that is what I\nsuspect is happening.\n\nFor example, I notice that the list of old refs is reused (kept in the\ntransport structure) when it reconnects to a different instance of\ngit-upload-pack to auto-follow the tags, and never refreshed from the\nactual remote end you are talking with.\n\nThis stale list of refs is passed all the way down to fetch_pack(),\nrepresenting _your_ idea of what they said they have, which does not\nmatch the reality if you are connecting to a different host (via DNS\nround robin). Even if there is no DNS round robin issue, if an update\nhappened on the host between the time you fetched the refs from there\nand you started a different instance of git-upload-pack for auto\nfollow the tags, the issue is the same (if you re-read the list of\nrefs from the new instance of upload-pack, you should be Ok, as the\nupload-pack on the other end should be internally consistent).\n\nAnother possibile problem area I did not check is if the current\ngit-fetch takes care of clearing various mark bits used and left by\nfind_common() and get_rev() in builtin-fetch-pack.c during the main\ntransfer, before it initiates another round to auto follow the tags.\nWhen we wrote fetch-pack the first time, we did not design it (most\nimportantly, find_common()) to be callable more than once, as cleaning\nthem was unnecessary overhead for the call-once-and-exit program.\n\nThe attached stops the stale set of refs from being used for common\nancestry computation. It may or may not fix your issue, but at least\nit should be more correct than what we currently have, I think.\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex ac335f2..c7cdd42 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -544,9 +544,16 @@ static int do_fetch(struct transport *transport,\n \n \tfetch_map = ref_map;\n \n-\t/* if neither --no-tags nor --tags was specified, do automated tag\n-\t * following ... */\n+\t/*\n+\t * If neither --no-tags nor --tags was specified, do automated tag\n+\t * following.\n+\t */\n \tif (tags == TAGS_DEFAULT && autotags) {\n+\t\tif (transport->remote_refs) {\n+\t\t\tstruct ref *stale = (struct ref *)transport->remote_refs;\n+\t\t\tfree_refs(stale);\n+\t\t\ttransport->remote_refs = NULL;\n+\t\t}\n \t\tref_map = find_non_local_tags(transport, fetch_map);\n \t\tif (ref_map) {\n \t\t\ttransport_set_option(transport, TRANS_OPT_DEPTH, \"0\");\n"},{"id":"70059","messageId":"7voda2yksf.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"7vir0byoc2.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-27T06:29:20Z","receivedAt":"2008-02-27T06:29:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Updates.\n\nI seem to have a reliable reproduction script, for this issue.\n\nAfter rebuilding your git with the following patch, running\nthe test script ./t000.sh would exhibit that \"no common refs\"\nwhile following the tag.\n\nThen rebuild your git with \"#if 0\" part enabled, and run the\ntest again, to see the problem fixed.\n\nThis adds --autofollow option which is _purely_ for debugging\nthis issue. The command named by the option is executed after\nthe command finishes the main transfer but before it starts the\nsecond transfer to auto follow the tags.\n\nThe test prepares two repositories (src0.git and src1.git) to\nsimulate DNS round robin server side. src0.git grows, src1.git\nmirrors it with a bit of lag. src.git is a symlink that is used\nto simulate DNS round robin. Initially it points at src0.git\n(more up-to-date one) and a clone to Len (dst.git) is made.\nAfter src0.git grows history while src1.git mirrors it with a\nlag, Len fetches again, first from src0.git but autofollowing\nconnection goes to src1.git.\n\nWhile I was futzing with the test script, I also observed\nanother error message \"fatal: not our ref\", but that was before\nI fixed the commit traversal order by giving them the test_tick\ntimestamps. It won't reproduce with the attached test script,\nbut the patch also seemed to fix it.\n\n---\n\n builtin-fetch.c | 12 +++++++\n t000.sh | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 107 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex ac335f2..79359ac 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -28,6 +28,7 @@ static const char *depth;\n static const char *upload_pack;\n static struct strbuf default_rla = STRBUF_INIT;\n static struct transport *transport;\n+static char *autofollow;\n \n static struct option builtin_fetch_options[] = {\n \tOPT__QUIET(&quiet),\n@@ -45,6 +46,8 @@ static struct option builtin_fetch_options[] = {\n \t\t \"allow updating of HEAD ref\"),\n \tOPT_STRING(0, \"depth\", &depth, \"DEPTH\",\n \t\t \"deepen history of shallow clone\"),\n+\tOPT_STRING(0, \"autofollow\", &autofollow, \"COMMAND\",\n+\t\t \"call the command just before autofollowing\"),\n \tOPT_END()\n };\n \n@@ -547,6 +550,15 @@ static int do_fetch(struct transport *transport,\n \t/* if neither --no-tags nor --tags was specified, do automated tag\n \t * following ... */\n \tif (tags == TAGS_DEFAULT && autotags) {\n+\t\tif (autofollow)\n+\t\t\tsystem(autofollow);\n+#if 0\n+\t\tif (transport->remote_refs) {\n+\t\t\tstruct ref *stale = (struct ref *)transport->remote_refs;\n+\t\t\tfree_refs(stale);\n+\t\t\ttransport->remote_refs = NULL;\n+\t\t}\n+#endif\n \t\tref_map = find_non_local_tags(transport, fetch_map);\n \t\tif (ref_map) {\n \t\t\ttransport_set_option(transport, TRANS_OPT_DEPTH, \"0\");\ndiff --git a/t000.sh b/t000.sh\nnew file mode 100644\nindex 0000000..e2c35d1\n--- /dev/null\n+++ b/t000.sh\n@@ -0,0 +1,95 @@\n+#!/bin/sh\n+\n+GIT_EXEC_PATH=`pwd`\n+PATH=`pwd`:/usr/bin:/bin\n+GITPERLLIB=`pwd`/perl/blib/lib\n+export GIT_EXEC_PATH PATH GITPERLLIB\n+\n+testdir=/var/tmp/fetch-test\n+mkdir -p \"$testdir\"\n+\n+cd \"$testdir\" || exit\n+test_tick=1112911993\n+\n+grow () {\n+\tj_bottom=\"$1\" j_top=\"$2\" i_top=\"$3\" tagit=\"$4\"\n+\tj=\"$j_bottom\"\n+\twhile test \"$j\" -le \"$j_top\"\n+\tdo\n+\t\ti=1\n+\t\twhile test \"$i\" -le \"$i_top\"\n+\t\tdo\n+\t\t\techo \"$j.$i\" >f\n+\t\t\tgit add f\n+\t\t\ttest_tick=$(($test_tick + 60))\n+\t\t\tGIT_COMMITTER_DATE=\"$test_tick -0700\" \\\n+\t\t\tgit commit -q -m \"$j.$i\"\n+\t\t\ti=$(($i + 1))\n+\t\tdone\n+\t\tif test -n \"$tagit\"\n+\t\tthen\n+\t\t\tgit tag -a -m \"Tag $j\" v$j\n+\t\tfi\n+\t\tj=$(($j + 1))\n+\tdone\n+}\n+\n+rm -fr src0.git src1.git dst.git\n+\n+# Prepare the very original. Pretend this is Linus\n+mkdir src0.git\n+cd src0.git\n+git init\n+grow 1 5 4 1\n+cd ..\n+\n+# Prepare a \"mirror\" that slightly lags behind.\n+mkdir src1.git\n+cd src1.git\n+GIT_DIR=. git init\n+git remote add -f --mirror origin ../src0.git/\n+cd ..\n+\n+# Prepare canonical symlink\n+rm -f src.git && ln -s src0.git src.git\n+\n+# Len clones and works\n+git clone file://$testdir/src.git/ dst.git\n+cd dst.git\n+grow 1 1 200\n+cd ..\n+\n+# Linus works more.\n+cd src0.git\n+grow 6 7 4 1\n+cd ..\n+\n+# Mirror it out\n+cd src1.git\n+git fetch\n+cd ..\n+\n+# Linus works further.\n+cd src0.git\n+grow 8 8 1\n+cd ..\n+\n+# Prepare \"switch\" script\n+echo >auto-switch.sh '#!/bin/sh\n+cd \"'$testdir'\"\n+case \"$(ls -l src.git)\" in\n+*src0.git*)\tnew=src1.git ;;\n+*src1.git*)\tnew=src0.git ;;\n+esac\n+echo \"Auto switching to $new\"\n+rm -f src.git && ln -s \"$new\" src.git'\n+chmod +x auto-switch.sh\n+\n+# Now Len fetches; the first goes to src0 (up-to-date one) but\n+# the autofollow goes to src1 (more stale one)\n+\n+rm -f src.git && ln -s src0.git src.git\n+\n+cd dst.git\n+git-fetch -v --autofollow=\"$testdir/auto-switch.sh\"\n+\n"},{"id":"70145","messageId":"alpine.LNX.1.00.0802271411280.19665@iabervon.org","threadId":"12019","inReplyTo":"7voda2yksf.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-27T19:28:15Z","receivedAt":"2008-02-27T19:28:15Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Correcting the transport code is important (and should probably be done in \ntransport.c, if possible), but I think we're being a bit silly in \nautofollowing tags anyway. If we decide to fetch T due to having T^{}, we \nshould tell the remote up front that we have T^{}, before we mention \nanything else, because it's obviously true and it's also absolutely \ncertain to make the remote immediately do the right thing. It's silly to \ndecide to fetch T because we will only need that one object, and then not \ninstantly tell the server we only need that one object. (And, as luck \nwould have it, yesterday I wrote code to cause for_each_ref return some\nspecific values in addition to and before the actual stored refs.)\n\nOf course, we shouldn't do this until we make the transport code more \ncorrect, because it's certain to hide any possible bug there.\n\nAm I missing something in my analysis?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70159","messageId":"7vskzeruit.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802271411280.19665@iabervon.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-27T20:53:14Z","receivedAt":"2008-02-27T20:53:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Correcting the transport code is important (and should probably be done in \n> transport.c, if possible), but I think we're being a bit silly in \n> autofollowing tags anyway. If we decide to fetch T due to having T^{}, we \n> should tell the remote up front that we have T^{}, before we mention \n> anything else, because it's obviously true and it's also absolutely \n> certain to make the remote immediately do the right thing.\n\nThat's correct, and the autofollowing code does so. You will\nnot know if you have T^{} until your primary transfer finishes,\nso you cannot roll autofollow into it.\n\nI think we can teach the upload-pack side to be more helpful and\nwith a protocol extension to send tag objects that are pointing\nat commits that will be included in the result, or something\nlike that, though. But that is outside the scope of 1.5.5; it\nwould be a moderate to large protocol surgery, and I suspect it\nmight even have to affect pack-objects.\n\n> It's silly to \n> decide to fetch T because we will only need that one object, and then not \n> instantly tell the server we only need that one object. (And, as luck \n> would have it, yesterday I wrote code to cause for_each_ref return some\n> specific values in addition to and before the actual stored refs.)\n\nYou won't know if you need only one object, so seeing that you\nhave T^{} and asking _only_ for T is _wrong_. Think of a tag\nthat points at another tag that points at the commit. You need\nto tell the other end \"I have T^{}, please give me T\", and that\nis exactly what the autofollowing does.\n"},{"id":"70160","messageId":"alpine.LNX.1.00.0802271605540.19665@iabervon.org","threadId":"12019","inReplyTo":"7vskzeruit.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-27T21:26:00Z","receivedAt":"2008-02-27T21:26:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 27 Feb 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Correcting the transport code is important (and should probably be done in \n> > transport.c, if possible), but I think we're being a bit silly in \n> > autofollowing tags anyway. If we decide to fetch T due to having T^{}, we \n> > should tell the remote up front that we have T^{}, before we mention \n> > anything else, because it's obviously true and it's also absolutely \n> > certain to make the remote immediately do the right thing.\n> \n> That's correct, and the autofollowing code does so. You will\n> not know if you have T^{} until your primary transfer finishes,\n> so you cannot roll autofollow into it.\n> \n> I think we can teach the upload-pack side to be more helpful and\n> with a protocol extension to send tag objects that are pointing\n> at commits that will be included in the result, or something\n> like that, though. But that is outside the scope of 1.5.5; it\n> would be a moderate to large protocol surgery, and I suspect it\n> might even have to affect pack-objects.\n\nUsing a single connection, either by just telling the remote that you want \nto autofollow tags, and it should therefore include any tags that point to \nany objects it includes, or by allowing you to list more refs that you \nwant after you've received the pack without disconnecting, would be quite \nnice, but I agree that it's a longer-term issue.\n\n> > It's silly to \n> > decide to fetch T because we will only need that one object, and then not \n> > instantly tell the server we only need that one object. (And, as luck \n> > would have it, yesterday I wrote code to cause for_each_ref return some\n> > specific values in addition to and before the actual stored refs.)\n> \n> You won't know if you need only one object, so seeing that you\n> have T^{} and asking _only_ for T is _wrong_. Think of a tag\n> that points at another tag that points at the commit. You need\n> to tell the other end \"I have T^{}, please give me T\", and that\n> is exactly what the autofollowing does.\n\nI don't see that. If the situation is:\n\n T - tag master\n / /\nO - A - O - O - B\n\nthe first fetch will see:\n\ntag: T\ntag^{}: A\nmaster: B\n\nOnly heads are interesting, so we fetch B. When we've fetched B, we find \nthat we now have tag^{}. So then we do a new fetch, and (bugs aside) list \nour now-current refs, including origin/master (=B) but not including A, \nbecause we don't (yet) have any refs for it. I'm suggesting that, while \nautofollowing tags, we should make a point of listing A, because we know \nit's relevant. Furthermore, if the remote doesn't have B (due to mirror \nskew, perhaps), listing B and not listing A (in particular) will lead to \nan inexact search for a common commit, when we know perfectly well that A \nis the closest common commit between what we have and tag.\n\nThe issue is that our starting set for our side of the negotiation is our \ncurrent refs, which doesn't include A. I'm suggesting that, for the \npurposes of autofollow, A should be included.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70190","messageId":"20080228004313.GQ8410@spearce.org","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802271605540.19665@iabervon.org","subject":"Re: warning: no common commits - slow pull","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-02-28T00:43:13Z","receivedAt":"2008-02-28T00:43:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Daniel Barkalow wrote:\n> On Wed, 27 Feb 2008, Junio C Hamano wrote:\n> > \n> > I think we can teach the upload-pack side to be more helpful and\n> > with a protocol extension to send tag objects that are pointing\n> > at commits that will be included in the result, or something\n> > like that, though. But that is outside the scope of 1.5.5; it\n> > would be a moderate to large protocol surgery, and I suspect it\n> > might even have to affect pack-objects.\n> \n> Using a single connection, either by just telling the remote that you want \n> to autofollow tags, and it should therefore include any tags that point to \n> any objects it includes,\n\nI agree its outside of 1.5.5, as we'd all like to see 1.5.5 happen\nsoon, but it could be 1.5.6 material, especially if someone starts\nworking on it sooner rather than later.\n\nIts actually probably not that difficult to implement. We'd just\nwant to include a size threshold, to prevent the client from\nsuddenly receiving a 1M tag (with say a build log embedded in it)\non an otherwise 100K transfer. Autofollowing by having the remote\ninclude the tags in the pack and send to the client would be more\nefficient for both sides then autofollowing with a second set of\nref requests, even if we are keeping the current connection open.\n\nI'll try to work up a prototype of this soon, say in the next week.\nObviously not for 1.5.5 but no reason to wait for the 1.5.6/1.6.0\nwindow to open before developing it. I think its a better approach\nthen supporting a second set of ref requests on the same connection.\n\n_IF_ we are going to support a second set of ref requests on the\nsame connection then we should also support being able to switch\nto another repository. I have 40 some odd repositories at day-job\nthat a shell script loops over and does fetches in, over SSH.\nSetting up and tearing down 40+ SSH connections (especially with tag\nfollowing!) sucks[*1*]. I think the X.org folks are in a similar\nposition as me[*2*].\n \n> If the situation is:\n> \n> T - tag master\n> / /\n> O - A - O - O - B\n> \n> the first fetch will see:\n> \n> tag: T\n> tag^{}: A\n> master: B\n> \n> The issue is that our starting set for our side of the negotiation is our \n> current refs, which doesn't include A. I'm suggesting that, for the \n> purposes of autofollow, A should be included.\n\nI agree. This is probably easier than coding the protocol extension above.\n:-)\n\n\n*1* I know all about the SSH connection sharing feature, it is\n unsupported on Cygwin. I'm on Cygwin at day-job. So that is\n a no-go.\n\n*2* X.org users are more likely to be on a UNIX platform where the\n OpenSSH connection share code works correctly.\n\n-- \nShawn.\n"},{"id":"70192","messageId":"7voda1nbzc.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802271605540.19665@iabervon.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-28T00:47:19Z","receivedAt":"2008-02-28T00:47:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Wed, 27 Feb 2008, Junio C Hamano wrote:\n>\n>> Daniel Barkalow writes:\n>> \n>> > Correcting the transport code is important (and should\n>> > probably be done...\n\nI thought about discarding the cached refs upon disconnect, but didn't do\nthat, because presumably a caller might want to:\n\n transport_get_remote_refs() to find what they have\n decide what it wants\n transport_fetch_refs() to ask for them\n do stuff about the refs obtained\n transport_disconnect() to finish the transfer\n still do stuff about the refs obtained\n\nand such a change would forbid the last step. But the only reason I\navoided to break such a potential caller was because I did not bother to\ncheck if such a caller exists, and not because I thought the above\nsequence is sane, so if you think it is saner to clean up the stale\ninformation upon disconnect, please do so.\n\n> Using a single connection, either by just telling the remote that you want \n> to autofollow tags, and it should therefore include any tags that point to \n> any objects it includes, or by allowing you to list more refs that you \n> want after you've received the pack without disconnecting, would be quite \n> nice, but I agree that it's a longer-term issue.\n\nYes, that is what I was talking about.\n\n>> You won't know if you need only one object, so seeing that you\n>> have T^{} and asking _only_ for T is _wrong_. Think of a tag\n>> that points at another tag that points at the commit. You need\n>> to tell the other end \"I have T^{}, please give me T\", and that\n>> is exactly what the autofollowing does.\n>\n> I don't see that. If the situation is:\n>\n> T - tag master\n> / /\n> O - A - O - O - B\n> ...\n> The issue is that our starting set for our side of the negotiation is our \n> current refs, which doesn't include A. I'm suggesting that, for the \n> purposes of autofollow, A should be included.\n\nBy telling the other end that we have B, we are implicitly telling that we\nhave A as well. Under normal situation, telling the other end we have A\ndoes not help nor hurt anything. Under abnormal situation (e.g. DNS round\nrobin switching the other end in the middle), the other end may say \"I\ndunno about B\", but the protocol is designed to negotiate and find that\nboth ends have A, by following the ancestry chain down, so I do not think\ntelling the other end that we have A helps that much. I however think\nthat such a change would help sweeping potential bugs under the rug by\nmaking them harder to trigger.\n\nBy the way, the situation I said your logic would break is this:\n\n ---o---A---o---o---B\n \\\n T---S\n\nBoth T and S are annotated tags, pointing at A and T respectively, and\nthey both peel to A. As long as you ask for both T and S you may be Ok,\nbut it feels still wrong. Commit walkers may grab S, die before grabbing\nT (git-native protocol is atomic with respect to objects transfer, so it\nwon't have such an issue).\n"},{"id":"70226","messageId":"20080228085038.GS8410@spearce.org","threadId":"12019","inReplyTo":"20080228004313.GQ8410@spearce.org","subject":"Re: warning: no common commits - slow pull","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-02-28T08:50:38Z","receivedAt":"2008-02-28T08:50:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> Daniel Barkalow wrote:\n> > On Wed, 27 Feb 2008, Junio C Hamano wrote:\n> > > \n> > > I think we can teach the upload-pack side to be more helpful and\n> > > with a protocol extension to send tag objects that are pointing\n> > > at commits that will be included in the result, or something\n> > > like that, though. But that is outside the scope of 1.5.5; it\n> > > would be a moderate to large protocol surgery, and I suspect it\n> > > might even have to affect pack-objects.\n> > \n> > Using a single connection, either by just telling the remote that you want \n> > to autofollow tags, and it should therefore include any tags that point to \n> > any objects it includes,\n> \n> I agree its outside of 1.5.5, as we'd all like to see 1.5.5 happen\n> soon, but it could be 1.5.6 material, especially if someone starts\n> working on it sooner rather than later.\n> \n> Its actually probably not that difficult to implement.\n\nOK, so I posted a fairly short series tonight (4 patches) that\nhandles some of the common cases in a fairly small amount of\ncode churn. It might just be 1.5.5-ish.\n\nDoing anything better is going to require a new protocol extension,\nwhich is already 1.5.6 material. In the mean time maybe Junio's\nearlier patch to try and drop the ref_map when we do open the new\nconnection is the way to deal with the round-robin DNS issues.\n\n-- \nShawn.\n"},{"id":"70271","messageId":"alpine.LNX.1.00.0802281026030.19665@iabervon.org","threadId":"12019","inReplyTo":"7voda1nbzc.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-28T15:53:18Z","receivedAt":"2008-02-28T15:53:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 27 Feb 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > On Wed, 27 Feb 2008, Junio C Hamano wrote:\n> >\n> >> Daniel Barkalow writes:\n> >> \n> >> > Correcting the transport code is important (and should\n> >> > probably be done...\n> \n> I thought about discarding the cached refs upon disconnect, but didn't do\n> that, because presumably a caller might want to:\n> \n> transport_get_remote_refs() to find what they have\n> decide what it wants\n> transport_fetch_refs() to ask for them\n> do stuff about the refs obtained\n> transport_disconnect() to finish the transfer\n> still do stuff about the refs obtained\n> \n> and such a change would forbid the last step. But the only reason I\n> avoided to break such a potential caller was because I did not bother to\n> check if such a caller exists, and not because I thought the above\n> sequence is sane, so if you think it is saner to clean up the stale\n> information upon disconnect, please do so.\n\nActually, I just realized something which should have been obvious: when \nwe reconnect, we get a list of the remote's refs, which we currently \ndiscard immediately. We should actually pass this list to fetch_pack() if \nwe just reconnected, so that the client side always does the interaction \nwith the right idea of the server's refs, and discard it afterwards. The \nfact that the user of transport_*() doesn't find out that the server \nside's refs change in the middle of the life cycle and can't find out in \nany way doesn't matter too much, so long as each actual connection is \ninternally consistant. (And the situation is no different from how it used \nto be with git-fetch.sh: if you get a different mirror later, you may \ndiscover that the server now doesn't have refs that it seemed to \nadvertize, but nothing weird happens.)\n\n> >> You won't know if you need only one object, so seeing that you\n> >> have T^{} and asking _only_ for T is _wrong_. Think of a tag\n> >> that points at another tag that points at the commit. You need\n> >> to tell the other end \"I have T^{}, please give me T\", and that\n> >> is exactly what the autofollowing does.\n> >\n> > I don't see that. If the situation is:\n> >\n> > T - tag master\n> > / /\n> > O - A - O - O - B\n> > ...\n> > The issue is that our starting set for our side of the negotiation is our \n> > current refs, which doesn't include A. I'm suggesting that, for the \n> > purposes of autofollow, A should be included.\n> \n> By telling the other end that we have B, we are implicitly telling that we\n> have A as well. Under normal situation, telling the other end we have A\n> does not help nor hurt anything.\n\nI think it could be slightly less server load if it doesn't have to walk \nfrom B to A, and I could make up something about cache locality.\n\n> Under abnormal situation (e.g. DNS round\n> robin switching the other end in the middle), the other end may say \"I\n> dunno about B\", but the protocol is designed to negotiate and find that\n> both ends have A, by following the ancestry chain down, so I do not think\n> telling the other end that we have A helps that much.\n\nI remember your tests that didn't quite show the problem leading to the \nautofollow connection getting ~100 objects, which is better than 700000 \nbut worse than the correct 1 for that case; I think it had found a commit \ncommit not too far away, but not the perfect one.\n\n> I however think\n> that such a change would help sweeping potential bugs under the rug by\n> making them harder to trigger.\n> \n> By the way, the situation I said your logic would break is this:\n> \n> ---o---A---o---o---B\n> \\\n> T---S\n> \n> Both T and S are annotated tags, pointing at A and T respectively, and\n> they both peel to A. As long as you ask for both T and S you may be Ok,\n> but it feels still wrong. Commit walkers may grab S, die before grabbing\n> T (git-native protocol is atomic with respect to objects transfer, so it\n> won't have such an issue).\n\nThey wouldn't write a ref for S, though, so the result would be consistant \nstill. If you ask for T and S and say you have A, everything should work.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70276","messageId":"alpine.LNX.1.00.0802281106390.19665@iabervon.org","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802281026030.19665@iabervon.org","subject":"[PATCH] Always use the current connection's remote ref list in git protocol","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-28T16:10:51Z","receivedAt":"2008-02-28T16:10:51Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"We always report to the user the list of refs we got from the first\nconnection, even if we do multiple connections. But we should always\nuse each connection's own list of refs in the communication with the\nserver, in case we got a different server out of DNS rotation or the\ntiming was surprising or something.\n\nSigned-off-by: Daniel Barkalow \n---\nThis should fix the same part of the problem that discarding \ntransport->remote_refs did, but without having transport.c try to do \nfoolish stuff and builtin-fetch need to tell it not to.\n\n transport.c | 9 +++++----\n 1 files changed, 5 insertions(+), 4 deletions(-)\n\ndiff --git a/transport.c b/transport.c\nindex 397983d..fc92311 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -622,6 +622,7 @@ static int fetch_refs_via_pack(struct transport *transport,\n \tchar *dest = xstrdup(transport->url);\n \tstruct fetch_pack_args args;\n \tint i;\n+\tstruct ref *refs_tmp = NULL;\n \n \tmemset(&args, 0, sizeof(args));\n \targs.uploadpack = data->uploadpack;\n@@ -634,15 +635,13 @@ static int fetch_refs_via_pack(struct transport *transport,\n \tfor (i = 0; i < nr_heads; i++)\n \t\torigh[i] = heads[i] = xstrdup(to_fetch[i]->name);\n \n-\trefs = transport_get_remote_refs(transport);\n \tif (!data->conn) {\n-\t\tstruct ref *refs_tmp;\n \t\tconnect_setup(transport);\n \t\tget_remote_heads(data->fd[0], &refs_tmp, 0, NULL, 0);\n-\t\tfree_refs(refs_tmp);\n \t}\n \n-\trefs = fetch_pack(&args, data->fd, data->conn, transport->remote_refs,\n+\trefs = fetch_pack(&args, data->fd, data->conn, \n+\t\t\t refs_tmp ? refs_tmp : transport->remote_refs,\n \t\t\t dest, nr_heads, heads, &transport->pack_lockfile);\n \tclose(data->fd[0]);\n \tclose(data->fd[1]);\n@@ -650,6 +649,8 @@ static int fetch_refs_via_pack(struct transport *transport,\n \t\trefs = NULL;\n \tdata->conn = NULL;\n \n+\tfree_refs(refs_tmp);\n+\n \tfor (i = 0; i < nr_heads; i++)\n \t\tfree(origh[i]);\n \tfree(origh);\n-- \n1.5.4.3.328.gcaed\n"},{"id":"70284","messageId":"7vy795j7d2.fsf@gitster.siamese.dyndns.org","threadId":"12019","inReplyTo":"alpine.LNX.1.00.0802281026030.19665@iabervon.org","subject":"Re: warning: no common commits - slow pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-28T17:52:57Z","receivedAt":"2008-02-28T17:52:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Actually, I just realized something which should have been obvious: when \n> we reconnect, we get a list of the remote's refs, which we currently \n> discard immediately. We should actually pass this list to fetch_pack() if \n> we just reconnected, so that the client side always does the interaction \n> with the right idea of the server's refs, and discard it afterwards. The \n> fact that the user of transport_*() doesn't find out that the server \n> side's refs change in the middle of the life cycle and can't find out in \n> any way doesn't matter too much, so long as each actual connection is \n> internally consistant. (And the situation is no different from how it used \n> to be with git-fetch.sh: if you get a different mirror later, you may \n> discover that the server now doesn't have refs that it seemed to \n> advertize, but nothing weird happens.)\n\nI think that would also be a valid way to solve this \"stale idea\nof what the other side has\" and can replace my weatherbaloon\npatch.\n\nAnother potential problem area is if find_common() does the\nright thing when it is called for the second time. I did not\ncheck if you clear COMMON, SEEN, COMPLETE etc. bits from the\nobject database before initiating the second round, but if you\ndidn't, I am afraid these bits left over from the primary\ntransfer might interfere the common ancestor discovery during\nthe second round.\n\n"},{"id":"70288","messageId":"alpine.LNX.1.00.0802281331220.19665@iabervon.org","threadId":"12019","inReplyTo":"7vy795j7d2.fsf@gitster.siamese.dyndns.org","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-28T18:36:56Z","receivedAt":"2008-02-28T18:36:56Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 28 Feb 2008, Junio C Hamano wrote:\n\n> Another potential problem area is if find_common() does the\n> right thing when it is called for the second time. I did not\n> check if you clear COMMON, SEEN, COMPLETE etc. bits from the\n> object database before initiating the second round, but if you\n> didn't, I am afraid these bits left over from the primary\n> transfer might interfere the common ancestor discovery during\n> the second round.\n\nAbsolutely; that was actually my first guess at why it was failing, and I \nthink it's a necessary aspect to the failure. Let me see if I can get your \ntest case to exhibit the problem for me and look into it further.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70396","messageId":"47C81A6B.1060905@freescale.com","threadId":"12019","inReplyTo":"20080228085038.GS8410@spearce.org","subject":"Re: warning: no common commits - slow pull","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-02-29T14:44:59Z","receivedAt":"2008-02-29T14:44:59Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> \"Shawn O. Pearce\" wrote:\n>> Daniel Barkalow wrote:\n\n>> I agree its outside of 1.5.5, as we'd all like to see 1.5.5 happen\n>> soon, but it could be 1.5.6 material, especially if someone starts\n>> working on it sooner rather than later.\n>>\n>> Its actually probably not that difficult to implement.\n> \n> OK, so I posted a fairly short series tonight (4 patches) that\n> handles some of the common cases in a fairly small amount of\n> code churn. It might just be 1.5.5-ish.\n> \n> Doing anything better is going to require a new protocol extension,\n> which is already 1.5.6 material. In the mean time maybe Junio's\n> earlier patch to try and drop the ref_map when we do open the new\n> connection is the way to deal with the round-robin DNS issues.\n\n\nHmmm... Might the any protocol extensions require a 1.6 release\nrather than a 1.5.x release? Or is this extension compatible\nenough that it can be transparent?\n\nThanks,\njdl\n"},{"id":"70399","messageId":"alpine.LNX.1.00.0802291211290.19665@iabervon.org","threadId":"12019","inReplyTo":"47C81A6B.1060905@freescale.com","subject":"Re: warning: no common commits - slow pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-29T17:14:54Z","receivedAt":"2008-02-29T17:14:54Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 29 Feb 2008, Jon Loeliger wrote:\n\n> Shawn O. Pearce wrote:\n> > \"Shawn O. Pearce\" wrote:\n> > > Daniel Barkalow wrote:\n> \n> > > I agree its outside of 1.5.5, as we'd all like to see 1.5.5 happen\n> > > soon, but it could be 1.5.6 material, especially if someone starts\n> > > working on it sooner rather than later.\n> > >\n> > > Its actually probably not that difficult to implement.\n> > \n> > OK, so I posted a fairly short series tonight (4 patches) that\n> > handles some of the common cases in a fairly small amount of\n> > code churn. It might just be 1.5.5-ish.\n> > \n> > Doing anything better is going to require a new protocol extension,\n> > which is already 1.5.6 material. In the mean time maybe Junio's\n> > earlier patch to try and drop the ref_map when we do open the new\n> > connection is the way to deal with the round-robin DNS issues.\n> \n> \n> Hmmm... Might the any protocol extensions require a 1.6 release\n> rather than a 1.5.x release? Or is this extension compatible\n> enough that it can be transparent?\n\nThe client and server exchange a list of supported features at the \nbeginning, and the difference in behavior would be at the end, so it \nshould be no problem to have the client ask for the chance to make further \nrequests and the server acknowledge that (or the server offer and the \nclient accept, depending on the order they do it, which I don't remember) \nwithout affecting programs that don't report the feature.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}