Diagnosing corruption

Repositories corrupt through power loss, disk failure, partial network sync, or buggy non-Git tools touching .git. Symptoms range from "fatal: bad object" to wrong content silently delivered. Diagnosis starts with fsck:

git fsck --full
git fsck --full --strict --no-dangling
git fsck --connectivity-only
git fsck --lost-found

--lost-found writes orphaned objects to .git/lost-found/ for manual inspection.

The all-in-one config

Putting the pieces together: this is a single configuration that applies the modern Git performance stack. Drop it into .git/config on a fresh clone, run the one-time tasks, and you have the recommended setup for repos with hundreds of thousands of files and active history.

Knowing your weight

Before optimizing, measure. Git ships git count-objects for basic stats; the third-party git-sizer from GitHub gives a deeper analysis with thresholds for trouble. Together they tell you whether your repo needs LFS, partial clone, or rewrite.

fast-export and fast-import

git fast-export serializes a repository to a stream of commands; git fast-import reconstructs a repository from one. Together they form Git's data interchange protocol — used by importers (cvs2git, hg-fast-export, p4-fast-export) and by tools like git filter-repo internally.

The cross-fork problem

Forge servers (GitHub, GitLab) host many forks of a repo together. Naively, a single packfile delta-compresses across all forks — efficient on disk, but inefficient when serving a single fork: the server must decompress through unrelated objects to reconstruct what one client wants. Delta islands constrain delta chains so that each fork's chains stay within its own object set.

The transport layer

Git's wire protocol historically interleaves client and server messages over a stateful connection. stateless-connect (introduced for protocol v2 over HTTP) decouples requests so each is independently routable, friendlier to load balancers and HTTP/2 servers.

Stateless flows

Under stateless-connect, the client sends a self-contained request (capabilities, wants, haves, options) over a single HTTP POST. The server answers with the response. No long-lived TCP state, no per-connection negotiation rounds.

Why v2

Protocol v0/v1 sent the server's full ref advertisement at the start of every fetch — a payload proportional to the number of refs. On repos with tens of thousands of refs (releases, PRs, mirrors), this dominated transfer time. Protocol v2 (default in Git 2.26+) lets the client request specific refs by name, dropping the upfront cost dramatically.

The shallow tradeoff

A shallow clone (--depth=N) downloads only the last N commits. Faster, smaller, but with caveats: many history-dependent operations become impossible or wrong. CI is the natural home for shallow clones, but only when you understand the limits.

Two parallelism wins

Two settings unlock significant speedups for everyday operations. core.preloadIndex parallelizes the lstat calls that git status makes; parallel checkout (Git 2.32+) parallelizes the file writes during git checkout, git switch, and git restore.

Repack budgets

When Git computes deltas during repack, it considers a window of candidate base objects per target. Larger windows produce smaller packs but use more memory and CPU. Tuning is essential for huge repos and constrained build runners alike.