sub-process: use gentle handshake to avoid die() on startup failure

When the configured subprocess command contains shell metacharacters (such as a space), prepare_shell_cmd() wraps it in "sh -c <cmd>". The shell itself always starts successfully, so start_command() returns zero even if the tool inside does not exist. The subsequent handshake then reads from a dead pipe and calls die() via the non-gentle packet_read_line(), killing the parent process instead of letting it handle the error. Before this change, a missing filter process at a path containing spaces produces a confusing error: $ git -c filter.myfilter.process="/path with space/tool" \ -c filter.myfilter.required=true add file.txt /path with space/tool: line 1: /path: No such file or directory fatal: the remote end hung up unexpectedly After this change, the proper error is reported: $ git ... add file.txt /path with space/tool: line 1: /path: No such file or directory error: could not read greeting from subprocess '/path with space/tool' error: initialization for subprocess '/path with space/tool' failed fatal: file.txt: clean filter 'myfilter' failed Switch the subprocess handshake from the dying packet_read_line() to packet_read_line_gently() so that a process that exits during startup produces an error return instead of killing the caller. This affects any subprocess consumer whose command path contains spaces. On Windows this routinely happens because programs live under "C:/Program Files/...", and MSYS2 path conversion can rewrite absolute paths to include that prefix. On POSIX it triggers whenever the configured path naturally contains a space or other metacharacter. convert.c (filter.<driver>.process, used by git-lfs and custom clean/smudge filters) is the primary affected consumer. Signed-off-by: Michael Montalbo <mmontalbo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>