Git 2.55 Ships Smarter Repacking That Makes Huge Repos 2x Faster

Git 2.55 is out, and it is one of the more infrastructure-heavy releases in recent memory. With contributions from over 100 people (33 of them first-timers), the release focuses on making large repositories cheaper to maintain, history editing more intuitive, and a handful of long-standing paper cuts finally get fixed. Here is what matters most.

The big one: smarter repacking for large repos

The headline feature is a new incremental repacking strategy built on top of multi-pack indexes (MIDX). To understand why this matters, a quick primer: Git stores your repo's content as objects (commits, trees, blobs) bundled into compressed packfiles. A MIDX is a single index over many packfiles, so Git can find any object without scanning every pack individually. For large repos receiving constant pushes, this is a critical performance tool.

The problem with a classic single-file MIDX is that even a tiny update forces a full rewrite of the entire index. Incremental MIDXs address that by storing a chain of MIDX layers. Each layer covers some collection of packs, and the chain file records the order of those layers. Appending a new layer to the tip of the chain does not invalidate the older layers, so Git can index newly created packs without rewriting a single MIDX that covers the entire repository.

Git 2.55 teaches git repack how to write those incremental MIDX chains directly:

$ git repack --write-midx=incremental
$ git repack --write-midx=incremental --geometric=2 -d

When those modes are used together, each repack creates a new tip layer, then decides whether adjacent layers should be compacted together. The default rule is controlled by repack.midxSplitFactor: if the accumulated object count in newer layers grows large enough relative to the next older layer, Git merges those layers into a single replacement layer.

The algorithm is elegant: it keeps the number of MIDX layers logarithmic in the total number of objects. The result is a compromise between two extremes. A single-file MIDX minimizes lookup complexity, but can require large rewrites during maintenance. A purely append-only incremental MIDX minimizes each write but allows the chain to grow without bound. Geometric incremental repacking keeps the number of layers logarithmic in the total number of objects, while ensuring that the newest, smallest layers are rewritten more often than older, larger ones.