git-clone failures abound

git-clone failures abound

[Jeff Garzik]

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?

	Jeff

Re: git-clone failures abound

[Junio C Hamano]

Jeff Garzik <jeff@garzik.org> 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.