Re: Cannot clone redirecting stdout

> On Fri, Sep 11, 2009 at 12:05:10PM -0400, Jeff King wrote:
> 
> > Ah. I have a theory. If I do a clone of git://gitorious.org/qt/qt.git,
> > the counting/compressing stages take a long time (I timed it at 1m40
> > before it actually sends any data). And looking at upload-pack.c, we
> > leave the 30-second alarm set while creating the pack. Meaning we die 30
> > seconds into creating the pack.
> > 
> > When progress is being displayed, however, the progress timer actually
> > uses SIGALRM, as well. So we are constantly resetting the timer and it
> > never goes off.
> 
> Hmm. Actually, this is not quite right. It looks like we call out to
> pack-objects as an external program, so there is no conflict with the
> signal. And we do proxy the output of pack-objects, which will keep our
> timer resetting every time we see a chunk of output. But pack-objects
> produces no output during the deltification phase, unless progress is
> turned on.  So we still hit our timeout in upload-pack during that
> phase.
> 
> So our options are:
> 
>   1. Turn off the timer during deltification, which could mean that it
>      would potentially go forever. But it's not controlled by the user.
>      I think the 'timeout' feature is really about the client just
>      opening the connection and sitting.
> 
>   2. Keep progress on during deltification, but just throw it away
>      instead of relaying it if no-progress is in effect.
> 
>   3. Accept that hitting the timeout during deltification _should_ cause
>      it to die. In that case, then the case with progress is wrong, and
>      we should stop resetting the timer just because we got some
>      progress output from pack-objects. But this may be redefining the
>      intent of --timeout. I don't know what the original intent was, or
>      what users of the feature are expecting.