Jeff King <peff@xxxxxxxx> writes: > I am not sure if I have followed all of this discussion, but I am of the > opinion that Git should not be doing any timeouts at all. > ... > If this is debugging output of the form "now I am calling wait() on all > of the filters", without respect to any timeout, that sounds reasonable. > Though I would argue that run-command should simply trace_printf() > any processes it is waiting for, which covers _any_ process, not just > the filters. That seems like a good match for the rest of the GIT_TRACE > output, which describes how and when we spawn the sub-processes. Yup, I agree that having trace_printf() report the wait for any process is the cleanest way to go. As you guessed the reason why Lars is bringing up "now we are waiting for this filter" is because I suggested it as a way to encourage users to file bugs when they see a hung Git. Originally Lars wanted to have a timeout on wait and after the timeout wanted to kill the process, and because I really did not want such a random "you are too slow to die, so I'll send a signal to you and exit myself without making sure you died" there, I suggested that if we were to have a timeout, that would be to timeout the wait only to have a chance to tell the user "we are stuck waiting on this thing" (and then go back to wait), as it would either be a buggy filter (i.e. the users need to debug their own filter code) or a buggy use of wait on Git side (i.e. we would want to hear about such bugs from them). Without such a "wait with timeout so that we can tell the user", we can still respond to "my 'git checkout' hangs forever" with "try running with GIT_TRACE" as you outlined above, so I do not think we need the timeout. Thanks for straightening us out.