Fixing Git error: fatal: fetch-pack: invalid index-pack output

What this error means

Git runs index-pack to validate and index an incoming packfile during clone/fetch. If index-pack fails or prints anything other than the expected machine-readable output, fetch-pack reports:

fatal: fetch-pack: invalid index-pack output

Common triggers:

• Truncated/corrupted network stream (proxies, flaky links, HTTP/2 bugs)
• SSH server printing banners or shell output
• Local disk full, I/O errors, antivirus interference
• Repository/object corruption (client or server)
• Very old Git versions or protocol incompatibilities

Quickstart: fixes in 60 seconds

Try these in order (stop when the command succeeds):

• Clean up a failed clone and retry fresh.
• Update Git to a recent version on client (and server, if you control it).
• Bypass proxies and force HTTP/1.1:
  • Inside a repo: git -c http.version=HTTP/1.1 fetch origin
• Reduce transfer size:
  • git -c protocol.version=2 fetch origin --filter=blob:none --depth=1
• For SSH remotes, remove shell startup output (ensure ~/.bashrc prints only for interactive shells).
• Verify disk space and disable antivirus scanning the repo path.

If it still fails, collect logs and diagnose as below.

Minimal working example (local, no network)

Use this to verify your client can run index-pack correctly. It clones a local bare repository via the file protocol.

set -euo pipefail

# Create a local bare remote with some history
rm -rf /tmp/remote.git /tmp/work
mkdir -p /tmp/work && cd /tmp/work

git init
printf "hello\n" > hello.txt
git add hello.txt
git commit -m "init"

git checkout -b feature
printf "more\n" >> hello.txt
git commit -am "update"

# Create a bare remote and push
mkdir -p /tmp/remote.git
cd /tmp/remote.git && git init --bare && cd -

git remote add origin /tmp/remote.git
git push -u origin --all

# Fresh clone (triggers pack transfer + index-pack locally)
cd /tmp
GIT_TRACE=1 GIT_TRACE_PACKET=1 git clone /tmp/remote.git client

# If this succeeds, your client-side index-pack works; network/proxy/SSH is suspect.

Step-by-step diagnosis and fixes

1. Start from a clean state

• Remove partial clones: rm -rf repo && reclone.
• In an existing repo that fails to fetch: git remote -v, then git fetch --all --prune -v.

1. Update Git

• Install a recent Git on the client. Old versions have known fetch/index-pack quirks.

1. Check disk, memory, filesystem

• Ensure sufficient free space and inodes. Packs can be large.
• On Windows, exclude the repository path from antivirus/EDR. Real-time scanning can corrupt or lock pack files.

1. Collect diagnostics

• Enable tracing for one failing attempt:

GIT_TRACE=1 GIT_TRACE_PACKET=1 GIT_CURL_VERBOSE=1 git fetch -v origin

• Look for truncated transfers, proxy headers, or unexpected server output.

1. If using HTTPS remotes

• Bypass corporate/system proxies for a test:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY
# If previously configured in Git:
git config --global --unset-all http.proxy || true
git config --global --unset-all https.proxy || true

• Force HTTP/1.1 to avoid buggy HTTP/2 middleboxes:

git -c http.version=HTTP/1.1 fetch origin

• Tame concurrency and timeouts for fragile networks:

git -c http.maxRequests=2 \
    -c http.lowSpeedLimit=0 -c http.lowSpeedTime=9999 \
    fetch -v origin

• Reduce data size to lower the chance of truncation:

git -c protocol.version=2 fetch origin --filter=blob:none --depth=1

1. If using SSH remotes

• Remove interactive shell output. Ensure your shell init files only print prompts/messages for interactive shells. For example in ~/.bashrc:

# Only run the interactive section when PS1 is set
case $- in *i*) ;; *) return ;; esac
# interactive-only settings below (echo, fortune, etc.)

• Increase logging for one attempt:

GIT_SSH_COMMAND="ssh -o LogLevel=ERROR" git fetch -v origin

• Verify the remote authorized command does not echo to stdout. Any stdout noise corrupts the pack stream.

1. Detect and repair local corruption

• Validate objects:

git fsck --full

• If corruption is reported, reclone is the safest fix. If reclone is expensive, try:

# Remove recent temporary packs and repack safely
git gc --prune=now --quiet

• If fetch still fails in this repo but works when recloning, prefer a fresh clone.

1. Server-side checks (if you control the server)

• Ensure git-upload-pack is available and recent.
• For HTTP servers/reverse proxies:
  • Disable response/body rewriting and on-the-fly compression of application/x-git.*
  • Allow large responses and long-lived connections.
  • Prefer HTTP/1.1 upstream to avoid buggy HTTP/2 translation.
• For SSH, remove login banners and non-interactive output.
• Monitor server memory and disk; OOM during pack generation leads to broken output.

Pitfalls to avoid

• Blindly increasing http.postBuffer: it affects push, not fetch; it does not fix this error.
• Reusing a partially created .git after a failed clone; always reclone clean.
• Aggressive antivirus or backup software touching .git/objects during fetch.
• Mixing very old client/server Git versions or custom wrappers that print to stdout.

Performance notes

• Prefer protocol v2 and partial clones to reduce transfer size:

git -c protocol.version=2 clone --filter=blob:none --depth=1 --no-tags origin clone-min

• Limit concurrent HTTP requests if your network or proxy struggles:

git -c http.maxRequests=2 fetch origin

• Use shallow fetches for CI to avoid large historical packs; deepen on demand:

git fetch --deepen=100 origin main

• Run occasional maintenance to keep packs healthy:

git maintenance start  # one-time enable background maintenance

Symptom-to-cause cheat sheet

• Happens only via VPN/office Wi‑Fi: likely proxy or MTU issues; force HTTP/1.1, reduce data, bypass proxy.
• Happens only via SSH: shell output or server hooks printing to stdout.
• Happens across protocols and machines: server resource issues or repository corruption.
• Happens only on one Windows host: antivirus/EDR or disk issues.

Tiny FAQ

• Q: Is this a client or server problem? A: Either. The message means the client saw unexpected output from index-pack. That can be due to a bad stream (network/proxy), server failure, or local corruption.

• Q: Will upgrading Git help? A: Often yes. Newer Git has protocol v2, better HTTP handling, and bug fixes.

• Q: Can I fix this by increasing http.postBuffer? A: No. That setting is for pushes. Focus on proxies, protocol version, and data size.

• Q: How do I get actionable logs? A: Use GIT_TRACE=1 GIT_TRACE_PACKET=1 GIT_CURL_VERBOSE=1 with one fetch/clone and inspect for truncation or server noise.

• Q: Should I prefer reclone over repair? A: If fsck reports issues or repeated fetches fail, a fresh clone is the fastest and safest path.