On Tue, Mar 19, 2024 at 07:37:21PM +0100, Ignacio Encinas wrote: > diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh > index 18fe1c25e6a0..613c766e2bb4 100755 > --- a/t/t6500-gc.sh > +++ b/t/t6500-gc.sh > @@ -395,7 +395,6 @@ test_expect_success 'background auto gc respects lock for all operations' ' > > # now fake a concurrent gc that holds the lock; we can use our > # shell pid so that it looks valid. > - hostname=$(hostname || echo unknown) && > shell_pid=$$ && > if test_have_prereq MINGW && test -f /proc/$shell_pid/winpid > then > @@ -404,7 +403,7 @@ test_expect_success 'background auto gc respects lock for all operations' ' > # the Windows PID in this case. > shell_pid=$(cat /proc/$shell_pid/winpid) > fi && > - printf "%d %s" "$shell_pid" "$hostname" >.git/gc.pid && > + printf "%d %s" "$shell_pid" "$(test-tool xgethostname)" >.git/gc.pid && Hmm. Before, we were compensating for a failure to run "hostname" by putting in the string "unknown". But I wonder if there were platforms where gethostname() simply fails (e.g., because the hostname is too long). In that case your test-tool returns the empty string, but git-gc internally will use the string "unknown". I think it may be OK, though. The failing exit code from test-tool will be ignored, and we'll end up with a file containing "123 " or similar. Normally we'd use kill() to check that the pid is valid, but with a mis-matched hostname we'll just assume the process is still around, and the outcome is the same. -Peff
