Git repositories are taking up space. Repack them, do not delete them

Guide · 6 min read · Updated September 2026

Repository history is the one thing on a developer's disk with no rebuild path. Caches come back. Dependencies reinstall. Commits do not.

They also get large. A repository with years of history, large binaries, or a lot of churn can carry a .git directory of several gigabytes. On the machine these guides are written from, one project's .git was 2.2 GB.

Repack first — it usually is enough

Git accumulates loose objects as you work and only consolidates them periodically. Forcing that consolidation is safe and often dramatic:

du -sh .git
git gc --prune=now
du -sh .git

Every reachable commit, branch and tag survives. What goes is redundancy: loose objects that are already inside a pack, and unreachable objects left behind by rebases and amended commits.

This is the only action Dustloft will ever offer on a repository. It scans for .git directories over 100 MB — below that, repacking is not worth the interruption — and the sole action attached to them is git gc. Deletion is not on the menu at any size.

The check that actually matters

Before any repository is deleted, the real question is whether its history exists anywhere but this disk. Almost everyone answers it wrong, because they check for a remote rather than checking the remote.

A configured remote is an address, not a backup. git remote get-url origin succeeding tells you a URL is written in the config. It tells you nothing about whether a single commit ever reached it.

The question that gives a real answer:

git ls-remote origin

Refs come back, the history exists elsewhere. Nothing comes back, the remote is empty and your working copy is the only copy in the world — regardless of what the config says.

This is the check that produced Dustloft. A repository with a GitHub remote configured looked obviously safe to delete during a manual cleanup. Nothing had ever been pushed. That near-miss is why the app runs ls-remote against every repository it finds, counts the refs, and marks a repository only copy — nothing pushed in red when the count is zero.

Before deleting any project folder

Check	Command	Wrong answer means
Does the history exist remotely?	git ls-remote origin	No refs — this is the only copy
Is anything uncommitted?	git status --porcelain	Output — unsaved work
Are there unpushed commits?	git log --branches --not --remotes	Output — local-only commits
Any stashes?	git stash list	Output — stashes are not pushed

Shrink the project, keep the history

Most of a project folder's size is usually not the repository at all. Dependencies and build output are typically far larger than .git, fully regenerable, and the right thing to remove first.