When using partial clones (filter=blob:none, which is automatically set
for sparse checkouts), `git checkout` lazily fetches missing blobs from
the promisor remote. If the remote is temporarily unavailable, this
network call fails and surfaces as a hard error with no retry.
The `fetch`, `getDefaultBranch`, and `lfsFetch` methods already use
retryHelper, but `checkout` and `submoduleUpdate` did not, despite both
performing network operations:
- `checkout`: fetches blobs on-demand from promisor remotes during
partial clone checkouts
- `submoduleUpdate`: clones/fetches submodule repositories
This was observed in production when GitHub's git service had a brief
outage, causing the checkout step to fail with:
fatal: unable to access '...': Failed to connect to github.com port
443 after 135272 ms: Couldn't connect to server
fatal: could not fetch <sha> from promisor remote
Wrapping both methods with the existing retryHelper (3 attempts with
10-20s jittered backoff) makes these operations resilient to transient
network failures, consistent with how fetch already behaves.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
b6a00b350f