How do you find and purge large blobs bloating a Git repository's clone size?

## Why the checkout size misleads you People judge repository weight by the working tree, but a clone transfers **history**: every version of every file that is still reachable. A 40 MB binary replaced twenty times is roughly 800 MB of objects even though the checkout shows one 40 MB file, because each version is a distinct blob and compressed binaries do not delta-compress well against each other. That is why deleting the file today does nothing for clone times. ## Measuring first Never rewrite before you know what you are rewriting. - `git count-objects -vH` reports loose and packed object counts and total pack size — the number that correlates with clone time. - `git rev-list --objects --all` lists every reachable object and, for blobs, the path it was seen at. - Piping that into `git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)'` yields type, SHA, size and path per line; sorting numerically on size and taking the tail shows the worst offenders and where they came from. - `git filter-repo --analyze` does this for you and writes size-by-path and size-by-blob reports under `.git/filter-repo/analysis/`, usually the faster route to a decision. What you are looking for is the shape of the problem: one accidental commit of a build artefact, a whole directory of fixtures, or a file type that keeps coming back. ## Purging On a fresh clone, pick the filter that matches the shape: - **By size**, when the offenders are unrelated one-offs: `git filter-repo --strip-blobs-bigger-than 10M` removes every blob above the threshold from all of history, regardless of path. - **By path**, when a directory or file type is the cause: `git filter-repo --path assets/renders/ --invert-paths` or `--path-glob '*.iso' --invert-paths`. Both rewrite every commit that contained the content and everything downstream, rewrite all branches and tags, prune commits that became empty, then expire reflogs and garbage-collect. Re-measure with `git count-objects -vH` to confirm the drop before publishing — if the size barely moved, your filter missed the real offenders and you should return to the analysis. ## The publishing cost This is where a size cleanup stops being a technical exercise. Every commit SHA from the earliest rewritten commit onward is new, so: - every clone in the organisation must be replaced, not pulled; - SHAs recorded outside the repository — deployment records, release notes, issue references, submodule pointers — now name commits that exist only in old copies; - signatures on rewritten commits no longer verify; - the force-push must cover every rewritten ref including tags. Budget for the coordination, pick a quiet window, and tell people before rather than after. ## Alternatives to rewriting Sometimes the rewrite is not worth it. Options to weigh: - **Leave history alone and stop the growth.** If clone time is tolerable, preventing new large blobs may be enough. - **Shallow or partial clones for consumers** who do not need full history — a per-consumer fix that requires no rewrite and breaks nobody, though it does not shrink the repository itself. - **Move binary assets out of the repository** entirely, into an artefact store or Git LFS, and rewrite once as part of that migration so the coordination cost is paid a single time. - **Archive and restart** for a repository whose history has little ongoing value: keep the old repository read-only and begin a fresh one. ## Preventing recurrence After a rewrite, add ignore rules for build outputs and a size check that runs before content can be published; otherwise the same binaries return and you will run the same painful rewrite next year. An interviewer listens for exactly that closing thought — the rewrite is the remediation, the prevention is the fix.