Re: [PATCH 4/9] run-command: add support for timeout in command finisher

From: Junio C Hamano <gitster@pobox.com>
Date: May 22, 2026, 00:10 UTC
Message-ID: <xmqqv7cgxq0o.fsf@gitster.g>
In-Reply-To: <cf52154c-1275-4a4b-957e-5aa17f22705c@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 22 quoted lines

> 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.