Hi, On Tue, 10 Feb 2009, Eric Raible wrote: > On Tue, Feb 10, 2009 at 2:24 AM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > 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>? > > 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. You could also try to set it to /bin/false, just so you know if the delay is caused by the shell startup. > 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. In my experience, such intermittent delays are often triggered by some (mostly unnecessary) calls to either DNS (which might hang for quite some time) or domain controllers (same). These can be triggered by shell startup looking for the user or host name. However, I am just fishing here, as I cannot begin to get an idea what is happening on your side. Also, it does not help that the platform is Windows, an OS I am mostly unfamiliar with. But there have to be profiling tools for that platform where you should be able to see what function is blocking (I assume it is a blocking call, of course). Ciao, Dscho -- To unsubscribe from this list: 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
