From: Siddh Raman Pant Date: Thu, 21 May 2026 09:59:09 GMT Subject: Re: [PATCH 4/9] run-command: add support for timeout in command finisher Message-ID: <2f7eea03273ffaacc50a9ae186673da88fc3345f.camel@oracle.com> In-Reply-To: On Thu, May 21 2026 at 12:51:51 +0530, Johannes Sixt wrote: > This is extremely suspicious. A communication protocl with a child > program that requires to kill the child looks like a design error. A > band-aid like this timeout should not be necessary for a well-behaved > child process. I do not think this is a protocol design error. The normal protocol does not require killing the helper: git sends one object id, the helper sends one bounded response, and the helper exits when git closes its pipes. 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. > If the (your?) problem is that the child process is actually not > well-behaved, then I suggest to use a middle-man as child process that > behaves well from the point of view of the git process, but can punish > the ill-behaved downstream process when needed. A middle-man would need the same timeout/termination/reaping logic, and git would still need to handle the middle-man itself hanging / failing. So I don't think it removes the problem, it just makes each user or deployment carry that process-supervision logic outside git. External notes are additive. If the helper misbehaves, the intended behavior is to warn once, disable that source for the rest of the process, and let git continue without those notes. That seems preferable to leaving git stuck in finish_command(). Thanks, Siddh