Jeff Garzik <jeff@xxxxxxxxxx> writes: > I've been seeing several reports lately, from different users on > various Linux platforms, with the same basic bug report > > * "git:// clone of linus's repo times out after 10 minutes" > > * someone says, "use rsync:// for the initial clone" > > * "it works, thanks!" > > People seems to note that this behavior only started recently. I > wonder if linux-2.6.git crossed some sort of size threshold that's too > much for kernel.org CPU load to bear? I wonder if git-clone is > attempting to delta-ify, when it really should just be sending the > objects in bulk? No, this was all my fault, and sorry about the confusion. GIT 1.4.1 contains commit 583b7ea3 which implemented a side-band communication for the upload-pack protocol to give progress bar output to the client downloaders, and in order to do so it changed the pipe structure of the process. It used to just fork two processes piped together that exec rev-list and pack-objects, and exec cleared alarm(). I mistakenly rewrote that part to have an extra process that oversees these two processes but the overseer does not exec and got killed by alarm(). This bug affects the server side. GIT 1.4.1 was installed on public kernel.org machines and the problem started happening after that. A fix was relatively simple, and I've issued GIT 1.4.1.1 with it last night -- the master branch also has the same fix. So when the kernel.org public machines are updated to 1.4.1.1 it should solve the problem. - : 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