Re: git-clone failures abound

Jeff Garzik [off-list ref] 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.