git clone: "fatal: Early EOF" — Large Repos and Flaky Networks

The transfer died mid-packfile: usually a network drop or a server-side cutoff on a huge clone. Shallow clone, partial clone filters, or resumable fetch strategies get the repo down reliably.

What you'll see

Root causes

Network instability killing the pack transfer

Long single-stream transfers (a multi-GB clone) are fragile: wifi/VPN/proxy drops end the stream. git's packfile download doesn't resume by default — every retry starts over.

Server-side limits (http.postBuffer, pack size, proxies)

Default buffers and corporate proxies choke on giant packs. The failure is instant-ish rather than percentage-deep — that timing distinguishes it from pure network loss.

Fix it

  1. Shallow clone first, deepen later
    git clone --depth 1 <url> && cd <repo> && git fetch --unshallow   # or fetch history in slices: --depth 100, 1000, ...
  2. Partial clone: skip blobs until needed
    git clone --filter=blob:none <url>   # server capability; on-demand blob fetch after checkout
  3. Raise transfer limits for borderline cases
    git config --global http.postBuffer 524288000 ; git config --global core.compression 0
  4. Stable-network workaround: clone in pieces
    # --single-branch to cut the pack, or fetch remotes/branches sequentially after a minimal init

Field note

blob:none + unshallow-on-demand gets you a working checkout at a fraction of the bytes — the modern default for huge repos, even on good networks. Early EOF deep into the transfer = network; instantly at connection = buffer/proxy limit. Same error text, different fixes.

Common questions

Does --depth 1 lose anything important?

History beyond the latest commit, until you deepen. The working tree is complete and fully functional: CI, builds, most development work fine on shallow clones, deepening on demand.

Why does the clone keep dying at the same percentage?

Consistent-percentage death points at a size-related cutoff (buffer/proxy), not random network loss. The postBuffer/compression route addresses it; random points of failure mean the network path itself.

Related fixes

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.