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

From: Johannes Sixt <j6t@kdbg.org>
Date: May 21, 2026, 14:36 UTC
Message-ID: <cf52154c-1275-4a4b-957e-5aa17f22705c@kdbg.org>
In-Reply-To: <2f7eea03273ffaacc50a9ae186673da88fc3345f.camel@oracle.com>

Am 21.05.26 um 11:59 schrieb Siddh Raman Pant:

Show 6 quoted lines

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

-- Hannes