Git Clone Hangs at "Receiving Objects" Percentage Indefinitely

A clone that hangs indefinitely at a specific percentage during "Receiving objects" typically means the actual data transfer has stalled — the connection was established successfully (which is why cloning started at all), but something is preventing the transfer from completing, whether that's genuine repository size, network instability, or an intermediate proxy interfering with the connection.

The Problem

Running git clone starts normally, showing initial progress, but then stalls at a specific percentage with no further progress and no error:

Cloning into 'large-repo'...
remote: Enumerating objects: 50234, done.
remote: Counting objects: 100% (50234/50234), done.
Receiving objects:  34% (17080/50234), 45.23 MiB | 1.2 MiB/s
# hangs here indefinitely, no further progress

Why It Happens

Several distinct causes can produce a stalled clone at this specific stage:

• A genuinely very large repository combined with a slow or unstable network connection, where the transfer is technically still progressing but extremely slowly — sometimes indistinguishable from a genuine hang without waiting significantly longer or investigating more directly
• A network interruption or instability causing the connection to effectively stall without either side detecting and cleanly closing the connection, leaving both ends waiting on data that will never arrive
• A corporate proxy, firewall, or antivirus/security software interfering with the long-lived connection a large clone requires, particularly software that inspects or buffers traffic in ways not well-suited to large, long-running transfers
• Insufficient client-side buffer or memory for an unusually large repository, causing Git itself to stall while attempting to process an especially large batch of incoming data

The Fix

First, determine whether the transfer is genuinely stalled or just extremely slow by checking your network activity directly, independent of Git's own progress display:

# Monitor actual network traffic to see if data is still flowing at all
# On Linux/macOS, tools like `nettop` or checking interface statistics
# can confirm whether bytes are still actively transferring

If data is still genuinely flowing, even slowly, the clone may simply need more time — for a very large repository over a constrained connection, waiting significantly longer (rather than assuming a hang) is sometimes the correct, if unsatisfying, answer.

If the transfer has genuinely stalled with zero ongoing network activity, cancel and retry with a shallow clone, which fetches only the most recent commit history rather than the repository's entire history, dramatically reducing the amount of data that needs to transfer successfully:

git clone --depth 1 https://github.com/example/large-repo.git

This gets you a working copy quickly for most purposes; if you later need the full history, you can fetch it incrementally:

git fetch --unshallow

Increase Git's HTTP post buffer size, which can help with transfer reliability for large repositories over HTTP(S), similar to the fix for large-push failures:

git config --global http.postBuffer 524288000

If you're behind a corporate network, proxy, or VPN, test cloning from a different network (a mobile hotspot, a home connection) to determine whether something specific to the restrictive network is interfering with the transfer — if the clone succeeds cleanly on a different network, the original network's proxy, firewall, or security software configuration is confirmed as the actual cause, requiring either a specific configuration adjustment on that network or working from a different connection when cloning large repositories.

Try switching between HTTPS and SSH protocols for the clone, since they're handled differently at the network level, and one may work more reliably than the other depending on your specific network's configuration or restrictions:

git clone git@github.com:example/large-repo.git
# or, if currently using SSH and it hangs, try HTTPS instead:
git clone https://github.com/example/large-repo.git

For genuinely very large repositories where full clones are consistently problematic, consider whether a partial clone (fetching blob data on-demand rather than all at once) better suits your actual needs:

git clone --filter=blob:none https://github.com/example/large-repo.git

This clones the repository's full commit history and tree structure immediately, but defers downloading the actual file contents (blobs) until they're specifically needed, which can significantly reduce the initial transfer size for repositories with a large amount of historical file content you don't need immediate access to.

Still Not Working?

If none of the above resolves the hang, and you have SSH access to the Git hosting server or can otherwise access the repository through an alternative means, consider downloading a repository archive/tarball directly (many Git hosting platforms offer this) as an alternative to a full git clone, then separately initializing a fresh local Git repository and adding the hosting platform as a remote — this sidesteps whatever specific issue is causing the clone transfer itself to stall, though at the cost of losing the repository's full commit history in the resulting local copy unless you later perform a proper fetch to reconstruct it.