Re: RFH: spawning pager takes long time when when unconnected from network

From: Eric Raible <raible@gmail.com>
Date: Feb 10, 2009, 10:53 UTC
Message-ID: <279b37b20902100253v3cfd8e45kefa6da7de2ea4a4b@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0902101124160.10279@pacific.mpi-cbg.de>

On Tue, Feb 10, 2009 at 2:24 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 16 quoted lines

> Hi,
>
> On Tue, 10 Feb 2009, Eric Raible wrote:
>
>> Johannes Sixt <j.sixt <at> viscovery.net> writes:
>>
>> > Do you have a directory in your PATH that points to a disconnected network
>> > drive? Do you use the default pager settings, or did you customize the pager?
>>
>> All components in my path are local.
>
> Could you run it with GIT_TRACE=<file>?
>
> Ciao,
> Dscho
>

The first thing I tried was to set GIT_TRACE=1, and it doesn't give much: trace: built-in: git 'diff' 'ss' '--name-only' trace: run_command: 'sh' '-c' 'less'

The long pause in question begins after the above output is produced but before the list of files is shown. The output is identical when setting GIT_TRACE to a file.

When I pipe the git diff to less or set core.pager="", then obviously it doesn't call run_command.

Since I can't really reproduce this in the debugger (because the "bug" is an intermittent delay of 3-10 seconds), I tried littering the code with trace_printf's. Didn't really help, partially because after the dup2 (which is part of spawning the pager process) they don't on stdout any longer. Now that I know about setting GIT_TRACE to a file perhaps this is worth trying again.

But once it started to look like the delay was in the xdiff machinery, I figured I was chasing a side-effect, and that the real problem was some interaction between the two processes. That's when I sent my first RFH to the list.

- Eric