Git repository size explained
Why is my Git repository so large?
Deleting a large file from your working tree does not necessarily remove its historical blob from the Git object database. GitSpire shows the exact objects and graph relationships behind repository size—locally and read-only.
Your working tree is not your whole repository
The files you currently see are one checkout. The .git directory also stores commits, trees, blobs, tags, refs, and packed object data needed to represent repository history.
Historical blobs remain after a file is deleted
A commit points to a tree, and tree entries point to blobs. Removing a path in a later commit does not rewrite earlier commits. If a current branch or tag can still reach an earlier commit containing the blob, that object remains reachable.
Reachability explains what current refs retain
GitSpire reports whether a blob is reachable from current refs and names the branches, tags, or other refs that can reach a commit tree containing it. It does not claim that an object belongs to one branch, and it does not infer renames.
Logical object size is not packed disk size
Git can compress objects and delta-compress related content in pack files. GitSpire's logical size is the exact uncompressed Git object payload size, not physical disk allocation or a share of a pack file.
Browser-local inspection
Inspect your repository locally.
GitSpire processes the repository you choose locally. Repository contents are not uploaded or changed.
Inspect your repository locally