From: Junio C Hamano Date: Fri, 22 May 2026 00:10:47 GMT Subject: Re: [PATCH 4/9] run-command: add support for timeout in command finisher Message-ID: In-Reply-To: Johannes Sixt writes: > Am 21.05.26 um 11:59 schrieb Siddh Raman Pant: >> The timeout is for the failure path, where the external helper has >> already stopped following that protocol or is blocked on something >> outside git's control. Since git starts the helper and puts it on the >> log/grep path, git also needs a bounded way to recover when that helper >> does not make progress. Otherwise an optional note source can prevent >> the main git command from completing. > > That Git communicates with a process that looks like it stopped is the > normal case, for example: > > - Output is sent to the pager. The user can take their time to study the > output. All the while, git waits patiently for the user to advance the > pager. > > - Git fetch transfers large amounts of data across the network. Most of > the time it waits for data to arrive and does nothing. The peer process > looks like it hangs. Git does not decide to kill the connection at any > time. It is the user's decision to do so. > > If the notes provider hangs, then it is not on Git to decide when it has > waited long enough. It is often the sticking sore point that there is no good timeout value that suites for everybody. If a protocol builds its own way to declare "this backend is slow, so please do not consider less than 3 seconds of nonaction something to worry about but kill it off if you waited more than that" to make the receiving/waiting end responsible for managing timeout, that might be workable, but it certainly feels like a kludge. The protocol can instead allow an "error - for your particular request, we couldn't come up with an answer within a reasonable time limit" response (in practice, "within time limit" does not have to be the only reason for such an error) to be returned, I think.