[jsegaran]

When a FETCH hits its timeout_ms, two things go wrong:

• The result is Internal, not Timeout. run_git returns GIT_STATUS_OTHER at the deadline, so a client can't tell a stalled remote from a server bug.
• Whatever git started keeps running. run_git kills only the git process. The ssh session, credential helper or local upload-pack under it is orphaned and runs until it finishes or blocks forever. With a remote whose upload-pack is sleep 30; git-upload-pack and timeout_ms: 500, the call returns after 0.5 s and the sleep survives.

Changes:

• A new engine status GIT_STATUS_TIMEOUT maps through native::Status::Timeout to the wire's Timeout.
• On Unix, run_git starts git in its own process group. On timeout or cancellation, kill_git sends SIGKILL to the whole group, then kills and reaps git as before. This needs libc on Unix and one unsafe call, which UNSAFE.md now covers. On Windows only git itself is killed, as before.

fetch_timeout_reports_timeout_and_kills_what_git_started (Unix) points remote.origin.uploadpack at a shell that records its pid and sleeps. It expects Status::Timeout and checks that the shell is gone within 5 s. It fails with Other before this change. With the status fix but without the group kill, it fails with upload-pack … outlived the fetch.

Found by fuzzing FETCH over a native session.

cargo test -p yas-git --test engine, cargo test -p yas-server --lib git, cargo clippy -p yas-git -p yas-server --all-targets -- -D warnings and cargo fmt --check pass.

Tag @indent to continue the conversation here.