SwifterPM restore fails on git hosts that reject shallow fetches (buf.build): no full-fetch fallback

Metadata

Source

tuist/tuist #12647

Updated

Aug 26, 2026

Details

What happened?

tuist install fails to restore Swift packages hosted on git servers that reject shallow fetches — in our case the generated SDKs on buf.build (https://buf.build/gen/swift/git/...).

SwifterPM’s source restore has exactly two strategies (Restore.swift, ensureSource):

downloadSourceArchive — only implemented for GitHub/GitLab, so it throws for any other host, and
shallowFetchCheckout — git fetch --depth=1 origin <revision>.

buf.build’s git server does not support shallow clients (uploadpack.allowShallow off), so step 2 fails with fatal: Server does not support shallow clients and there is no full-fetch fallback. A plain (non-shallow) git fetch origin <revision> of the same pin succeeds against the same server, so a fallback to a full fetch when the server rejects shallow would fix this.

Expected: the restore falls back to a non-shallow fetch (like SwiftPM does) when the server rejects --depth, instead of failing the whole install.

Workaround: TUIST_USE_SWIFTERPM=0 (works fine).

How do we reproduce it?

No auth needed — the package is public. The failing git operation can be reproduced standalone:

mkdir repro && cd repro && git init .
git remote add origin https://buf.build/gen/swift/git/1.24.2-20241219201140-e93e34f48be0.1/googleapis_googleapis_grpc_swift.git

# what SwifterPM runs — fails:
git fetch --depth=1 origin 13244576b21a339b077ed7ef1e029710bcf2ae24
# fatal: Server does not support shallow clients

# same fetch without --depth — succeeds:
git fetch origin 13244576b21a339b077ed7ef1e029710bcf2ae24

Through tuist: add the package to Tuist/Package.swift of any generated project and run tuist install with a cold source cache:

.package(url: "https://buf.build/gen/swift/git/1.24.2-20241219201140-e93e34f48be0.1/googleapis_googleapis_grpc_swift.git", exact: "1.24.2-20241219201140-e93e34f48be0.1")

(Resolution itself succeeds — SwiftPM handles it — only the SwifterPM restore step fails. A warm source cache masks the bug, which is why this surfaced for us only after a version bump left the cache cold for these pins.)

Error log

✖ Error
  failed to restore googleapis_googleapis_grpc_swift from https://buf.build/gen/swift/git/1.24.2-20241219201140-e93e34f48be0.1/googleapis_googleapis_grpc_swift.git at 13244576b21a339b077ed7ef1e029710bcf2ae24: could not fetch any candidate location for https://buf.build/gen/swift/git/1.24.2-20241219201140-e93e34f48be0.1/googleapis_googleapis_grpc_swift.git:
    - https://buf.build/gen/swift/git/1.24.2-20241219201140-e93e34f48be0.1/googleapis_googleapis_grpc_swift.git: fatal: Server does not support shallow clients
fatal: the remote end hung up unexpectedly

macOS version

26.6.2

Tuist version

4.205.0

Xcode version

26.6

Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.

No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments

D

dosubot[bot] Aug 26, 2026

Hi @kvyatkovskys! I’m Dosu and I’m helping the Tuist team.

Your diagnosis is spot-on. In ensureSource, two strategies are tried in sequence:

downloadSourceArchive — throws for anything that isn’t GitHub or GitLab [1]
shallowFetchCheckout — runs git fetch --depth=1 origin <revision> with no fallback to a full fetch [2]

When buf.build rejects the shallow fetch, there is no recovery path and the entire restore fails. The fix would involve catching the --depth=1 failure inside shallowFetchCheckout and retrying with a plain git fetch origin <revision> before propagating the error.

Since this is a clear bug with a well-understood fix, it would be great if you could share it on the Tuist community forum under the bugs category so the maintainers can track and discuss the implementation. In the meantime, your TUIST_USE_SWIFTERPM=0 workaround is the right call.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.