A clone can run for twenty minutes, reach a few percent, and collapse into four errors at once: RPC failed, curl 56, early EOF, and index-pack failed. Those messages are usually one failure viewed from different layers—not four independent Git problems.

What the error chain means

  • curl 56 means libcurl failed while receiving network data.

  • GnuTLS recv error (-54) reports a TLS receive/pull failure from Git’s GnuTLS-backed HTTP stack.

  • early EOF means the pack stream ended before Git received the advertised object data.

  • index-pack failed is downstream: Git cannot validate/index an incomplete packfile.

  • Likely causes include an unstable link, proxy/firewall reset, VPN path, server interruption, or a large transfer exposing a marginal connection.

1. Retry once—and learn from the result

Terminalbash
git clone https://github.com/beagleboard/linux.git

Why one retry is useful

  • git clone creates a new directory and requests repository objects from the remote.

  • A successful retry strongly suggests a transient disconnect; repeated failure at similar points suggests a persistent network or middlebox problem.

  • Remove or rename an incomplete destination directory before retrying so Git does not stop because the path already exists.

  • Repeatedly downloading a multi-gigabyte history is expensive; after one clean retry, switch to diagnosis or a smaller clone.

2. Confirm Git, URL, and network scope

Terminalbash
git --version
git ls-remote https://github.com/beagleboard/linux.git HEAD

What this isolates

  • git --version identifies the client whose HTTP/TLS behavior you are testing; update an obsolete distro package before deep debugging.

  • git ls-remote ... HEAD transfers refs rather than the full pack, so success proves basic DNS, TLS, HTTP, and repository access—not sustained large-transfer health.

  • A failure here points toward URL, credentials, certificate trust, proxy, DNS, or firewall issues rather than repository size.

3. Reduce the history when you only need current code

Terminalbash
git clone --depth 1 --single-branch https://github.com/beagleboard/linux.git

The shallow-clone tradeoff

  • --depth 1 requests only the newest commit history boundary.

  • --single-branch limits history to the selected/default branch and is implied by depth unless overridden.

  • The smaller pack reduces exposure to flaky links and is suitable for builds that do not need history.

  • History-dependent operations such as old-version archaeology, some merge-base calculations, and broad blame/log work remain limited until the repository is deepened.

4. Prefer a partial clone when you need commit history

Terminalbash
git clone --filter=blob:none https://github.com/beagleboard/linux.git

Why blob filtering is different

  • --filter=blob:none asks a capable server to omit file-content objects until an operation needs them.

  • Unlike --depth, the clone retains commit and tree history, making it better for many large-repository workflows.

  • Later checkout, diff, blame, or merge operations may fetch missing blobs and therefore still require network access.

  • The remote must support partial-clone filtering.

5. Inspect proxy configuration and compare networks

Terminalbash
git config --show-origin --get-regexp '^http\..*proxy$|^https\..*proxy$'
env | grep -iE '^(http|https|all|no)_proxy='

Reading the proxy check

  • --show-origin reveals which Git config file supplied a proxy value.

  • Environment variables can override or supplement Git configuration; credentials in output must be redacted before sharing logs.

  • A corporate TLS-inspection proxy, VPN, antivirus filter, or captive network may reset long-lived HTTPS transfers.

  • Do not delete organization-managed proxy settings blindly; compare on an approved alternate network or ask the network administrator.

6. Capture a focused HTTPS trace

Terminalbash
GIT_TRACE=1 GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 \
+  git clone https://github.com/beagleboard/linux.git

Risk level: caution. Review the command before running it.

What the trace can prove

  • GIT_TRACE=1 shows Git command execution and transport decisions.

  • GIT_TRACE_CURL=1 exposes HTTP/cURL events; GIT_TRACE_CURL_NO_DATA=1 suppresses payload bodies.

  • Logs can still contain URLs, usernames, headers, cookies, or credentials depending on configuration. Treat them as sensitive and redact before sharing.

  • Look for proxy negotiation, TLS alerts, HTTP status, disconnect timing, and whether failures recur consistently.

7. Try another supported transport

Terminalbash
git clone git@github.com:beagleboard/linux.git

When SSH helps

  • The SSH URL bypasses Git’s HTTPS/libcurl path and can avoid a broken HTTP proxy.

  • SSH requires an authorized key and network access to the SSH service; it is not an authentication bypass.

  • GitHub documents SSH over port 443 for networks that block ordinary SSH, but proxies can still interfere.

  • If HTTPS and SSH both fail on one network but succeed elsewhere, investigate the network path rather than Git object storage.

  • Do not set `http.sslVerify=false`: it removes certificate verification and exposes credentials/code to interception.

  • Do not inflate `http.postBuffer` for a clone: Git documents it as a smart-HTTP POST buffer and says increasing it is generally ineffective for most push problems; a clone receive failure is not fixed by allocating a huge upload buffer.

  • Do not set enormous global timeouts first: doing so can hide a dead connection and slow diagnosis.

  • Do not repeatedly delete a useful partial download without checking state: for a failed fresh clone the directory is usually disposable, but confirm it contains no local work.

  • Do not download repository archives from untrusted mirrors: source authenticity matters.

Symptom-driven troubleshooting

  • Fails once, succeeds immediately: transient congestion or disconnect; no permanent config change is justified.

  • Fails only on office Wi-Fi/VPN: proxy, TLS inspection, firewall, or path timeout; involve the administrator with redacted traces.

  • Small repositories work, one huge repository fails: use shallow/partial clone and test sustained connectivity/storage.

  • `ls-remote` fails: fix URL, access, DNS, TLS trust, or proxy before optimizing clone size.

  • Failure occurs during `index-pack` without network errors: verify free disk space, filesystem health, memory pressure, and antivirus interference.

  • HTTP fails but SSH works: remain on the supported SSH transport or repair the HTTP path.

Primary references