Packfiles, GC, and Reachability

## Two representations of the same object Git's object database is content-addressed: every blob, tree, commit and annotated tag is stored under the hash of its contents. That hash is computed over the object's *logical* content (a header of the form `<type> <size>\0` followed by the bytes), never over how the bytes happen to sit on disk. This is why Git can keep the same object in two completely different physical layouts without anything else in the system noticing. **Loose objects** are the write-path format. When you run `git add` or `git commit`, each new object is deflated with zlib and written as its own file at `.git/objects/<first two hex chars>/<remaining hex chars>`. The two-character directory is just fan-out so no single directory holds a million entries. Loose objects are simple and cheap to create — one file, one write, no coordination with anything already stored — and they are individually compressed but never compressed *against each other*. **Packed objects** are the storage format. A packfile is one big `.pack` file under `.git/objects/pack/` containing many objects concatenated together, accompanied by a `.idx` file. Recent Git versions may also write a `.rev` reverse-index file alongside them. ## What the .idx file does A packfile on its own is not randomly accessible: you cannot know where object `3b18e51…` lives inside a multi-gigabyte file. The `.idx` is a sorted index of every object ID in the pack together with its offset into the `.pack`, plus a 256-entry fan-out table keyed by the first byte of the ID. Looking an object up is a fan-out lookup followed by a binary search — logarithmic, not a scan. The `.idx` contains no object data; delete it and Git can rebuild it from the pack with `git index-pack`. ## Delta compression The real win in a packfile is that objects are not all stored whole. During packing, Git sorts candidate objects heuristically (by type, path name, size) and, for each object, searches a sliding *window* of nearby candidates for a good base. If one is found, the object is stored as a **delta** — a compact instruction stream saying "copy these byte ranges from the base, then insert these literal bytes" — and the result is zlib-compressed on top of that. A base may itself be a delta, forming a **delta chain**. Several rules constrain this. Git only deltifies objects of the same type, so a blob is never delta'd against a tree. Deltas may point at bases either by offset within the same pack or by object ID, but the base must be resolvable — a "thin" pack whose bases live elsewhere is only legal in transit and is completed on receipt. Chain depth is bounded by `pack.depth` (default 50) and the search width by `pack.window` (default 10), because a long chain costs CPU on every read: reconstructing the object means walking back to a whole base and applying each delta in turn. Blobs above `core.bigFileThreshold` (default 512 MiB) are stored undeltified. `git gc --aggressive` mainly widens the search window — `gc.aggressiveWindow` defaults to 250 — while `gc.aggressiveDepth` defaults to 50. A crucial consequence: delta bases have nothing to do with commit order. Git may store an *older* revision of a file as a delta against a newer one, because packing prefers newer objects as whole bases so that recent history reads fast. This is not a per-file version chain the way older centralized systems worked. ## When packing happens Packing is not automatic on commit. It happens when `git gc` runs — explicitly, or via `git gc --auto`, which many commands invoke and which triggers once loose objects exceed `gc.auto` (default 6700) or the number of packs exceeds `gc.autoPackLimit` (default 50). A clone arrives already packed, because the sending side generates a packfile for the transfer. `git repack -a -d` rewrites everything into one pack and deletes the now-redundant ones; `git unpack-objects` does the reverse for a pack fed on stdin. ## Seeing it yourself `git count-objects -v` reports `count` and `size` for loose objects (size in KiB) against `in-pack`, `packs` and `size-pack` for packed ones. `git verify-pack -v` on an `.idx` lists every object with its type, size, packed size and delta chain depth, which is how you find what is actually consuming space. Because the physical layout is invisible above the object layer, none of this affects correctness — it affects clone time, disk footprint, and how fast history traversal reads from disk.