fix(source-control): allow clones to finish without a deadline

[Gigioxx]

Cloning a large repository or using a slow connection fails after two minutes because the server kills Git at a fixed deadline.

Set the clone timeout to null, matching the existing push behavior. This is one production-line change in the shared service used by web, desktop, and mobile.

Reproduced before the fix with the real Git driver and a simulated three-minute process: Git command timed out., wrapped in the reported generic repository error. The same virtual-clock regression now passes. All 8 repository-service tests, server typecheck, targeted lint, and formatting pass. No network download or browser verification is claimed.

Fixes #9780.

Created with GPT-6 in Codex.

---

Note

Medium Risk
Shared clone path for web, desktop, and mobile no longer enforces a server deadline, so stuck clones can run indefinitely until killed elsewhere, though behavior is intentional and output limits remain.

Overview
Removes the fixed two-minute kill on server-side git clone, so large repos or slow networks are no longer aborted with a timeout error.

SourceControlRepositoryService.cloneRepository now passes timeoutMs: null to the Git driver instead of 120_000, aligning clone with other long-running Git work (e.g. push). Output is still capped at 256 KiB.

A new effect test simulates a clone that exits after three minutes using TestClock and a mocked child process, asserting the operation completes successfully.

^{Reviewed by Cursor Bugbot for commit 63bb6f3. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Remove 120-second timeout from cloneRepository Git command

The Git clone process previously had a fixed 120-second execution deadline, which could abort large or slow clones before they finished. cloneRepository now runs with no configured timeout, so the command continues until it completes or fails on its own. A new test uses a fake Git process with a simulated three-minute runtime to verify the clone still succeeds past the old limit.

• Risk: removing the timeout means a hung clone process can run indefinitely; any caller relying on the 120s deadline will now block until the process exits or fails.

^{Macroscope summarized 63bb6f3.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The production clone path now has no deadline instead of the previous 120-second default, allowing slow clones to finish but also changing the behavior of every existing clone request. The regression test covers the intended long-running case, but the product-default change warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[Gigioxx]

Keeping the current fix and leaving the default-behavior decision for human review.

The fixed deadline is the cause of #9780: clone duration depends on repository size and connection speed, so raising the limit would only move the failure threshold. timeoutMs: null follows the existing Git push behavior.

The tradeoff is that a stalled clone no longer has an application-imposed deadline. Explicit cancellation or stall detection would be separate work; this PR does not add either. The regression exercises the real Git timeout logic with a simulated three-minute process and fails before the fix. CI, Bugbot, and Macroscope's correctness check passed.

Could a maintainer review and approve this default-behavior change before merge?