Re: What's cooking in git.git (Mar 2026, #06)

From: Jeff King <peff@peff.net>
Date: Mar 18, 2026, 04:04 UTC
Message-ID: <20260318040423.GA2858991@coredump.intra.peff.net>
In-Reply-To: <xmqqh5qfmhdd.fsf@gitster.g>

On Mon, Mar 16, 2026 at 05:25:50PM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> * aa/reap-transport-child-processes (2026-03-12) 1 commit
>  - transport-helper, connect: use clean_on_exit to reap children on abnormal exit
> 
>  A few code paths that spawned child processes for network
>  connection weren't wait(2)ing for their children and letting "init"
>  reap them instead; they have been tightened.
> 
>  Will merge to 'next'?
>  source: <20260312214945.4050010-1-cshung@gmail.com>

I think this is responsible for CI failures on Windows in t0061.24. That test does this:

  test_expect_success MINGW 'can spawn .bat with argv[0] containing spaces' '
          bat="$TRASH_DIRECTORY/bat with spaces in name.bat" &&
  
          # Every .bat invocation will log its arguments to file "out"
          rm -f out &&
          echo "echo %* >>out" >"$bat" &&
  
          # Ask git to invoke .bat; clone will fail due to fake SSH helper
          test_must_fail env GIT_SSH="$bat" git clone myhost:src ssh-clone &&
  
          # Spawning .bat can fail if there are two quoted cmd.exe arguments.
          # .bat itself is first (due to spaces in name), so just one more is
          # needed to verify. GIT_SSH will invoke .bat multiple times:
          # 1) -G myhost
          # 2) myhost "git-upload-pack src"
          # First invocation will always succeed. Test the second one.
          grep "git-upload-pack" out
  '

But after applying the patch from this topic, the second invocation of the bat file never writes its arguments to the "out" file. I can guess what is happening is:

  1. .bat files seem to write the commands they are running to stdout
     (it has been decade or three since I wrote a .bat file, but I think
     that is just a DOS-ism, and it happens both before and after this
     topic).

  2. Git sees garbage from ssh (really the .bat file) and complains with
     "bad line length character". This also happens before the patch.

  3. Now here's where we diverge. With this topic, Git will then kill()
     the child process and wait to reap it. Presumably this is racy with
     the .bat file running the actual "echo" command, and as a result,
     we never see anything hit the "out" file.

So I think we could perhaps just call the test badly written. It _could_ use a more realistic fake-ssh setup that would actually complete the clone. But I'm not sure how, since the .bat file insists on dumping crap to stdout. Commit 71f4960b91 (t0061: fix test for argv[0] with spaces (MINGW only), 2019-10-01) seems to imply this came from a real-world case, so maybe there is some way to make .bat files work better.

It could perhaps use some other mechanism that runs a command, like ext-diff. Or even "test-tool run-command run-command $bat".

But it does make me wonder if there might be real-world cases that would be unhappy to have the sub-process killed immediately (assuming it was going to exit on its own after doing some cleanup, flushing buffers, etc).

-Peff