Git 2.51.0 ships with a new repacking behavior that shrinks multi-pack indexes by up to 38% and writes them 35% faster, while also introducing portable stashes and a path‑walk packing algorithm that produces smaller packs. The release deepens Git’s ability to handle monorepos and large repositories, and it delivers several quality‑of‑life improvements for Windows developers.

Cruft‑aware MIDX repacking closes a long‑standing reachability gap

To understand the change, recall how Git stores objects. Each packfile gets an index (.idx) that maps object hashes to offsets. When many packs accumulate, lookups degrade to O(M log(N)). A multi‑pack index (MIDX) provides a single index across all packs, bringing lookups down to O(log(N)). Reachability bitmaps then sit on top of the MIDX to answer “is X reachable from commit Y?” almost instantly.

Unreachable objects are kept in separate “cruft packs” to avoid polluting the main pack structure. Until 2.51, Git kept cruft packs outside the MIDX to keep the index smaller. That created a subtle but serious flaw: if a cruft‑only object later became reachable from a bitmapped commit, the bitmap had no bit position for that object, and bitmap generation would fail.

Git 2.51 fixes this by altering how repack decides what goes into the non‑cruft set. When building a new pack, Git now duplicates any object—and its ancestors—whose only copy lives in a cruft pack. Repeated across a repository, this guarantees that the set of non‑cruft packs is closed under reachability. With the hole plugged, the MIDX no longer needs to include cruft packs, yet bitmaps can always be written correctly.

A new configuration option, repack.MIDXMustContainCruft, enables this behavior. At GitHub, applying it to the primary monorepo shrank MIDXs by about 38%, cut MIDX write times by 35%, and improved read performance by roughly 5%. The trade‑off is that duplicating objects during repack increases temporary disk usage, so large‑repository operators should plan for extra free space and run repacks during maintenance windows.

How to try it

  • Clone a mirror: git clone --mirror <repo-url>
  • Repack with the new behaviour: git repack -a -d -b -m (after setting repack.MIDXMustContainCruft to true).
  • Monitor df, I/O, and CPU. For normal desktop repositories the defaults remain safe and the benefits less dramatic.

Path‑walk packing delivers smaller packs by grouping objects by path

Delta compression has always relied on a heuristic: compute a “name hash” from each object’s path, sort by that hash, and slide a window over the sorted list to find good delta bases. The old hash over‑weighted the last 16 characters of the path. Git 2.49’s “name‑hash v2” improved on that by considering more of the directory structure.

Git 2.51 takes a different approach entirely. Instead of walking objects in revision order and hoping the hash‑based sort groups related blobs, the new “path walk” method emits all objects that live at a given path at once. This exposes natural clusters—files that really are the same across history—and lets the delta engine find better base candidates without relying on the name‑hash heuristic.

The result is packs that are often significantly smaller than even those produced with name‑hash v2. The timings are competitive because path‑walk traversal is linear and avoids re‑scanning the same paths. Developers can activate it with the --path-walk flag:

git repack -a -d --path-walk

Combining it with MIDX and bitmaps works as expected:

git repack -a -d --path-walk -b -m

Memory and CPU tuning options (--threads, --window, --depth, --window-memory) remain effective. Repositories with many repeated file paths or large binary files in consistent locations are likely to benefit most. As always, test on a mirror before applying to production.

Stash export and import: portable stashes for the first time

Git’s stash has always been a local convenience. Under the hood, pushing to the stash creates three internal commits: one for staged changes, one for working‑directory changes, and a merge‑like commit that ties them together. The stash ref (refs/stash) stores only the latest entry; older entries live in the reflog. Moving stashes between machines required arcane scripting.

Git 2.51 introduces an alternative internal representation where stash entries form a chain linked by an additional parent pointer. That turns the stash into a normal commit log with four (or sometimes five) parents. Two new subcommands capitalize on this:

  • git stash export --to-ref <ref> writes the selected stash entries as a linear commit sequence to the given ref (e.g., refs/stashes/my-stash).
  • git stash import <commit> reads that sequence and appends the entries to the local stash list.

A typical cross‑machine workflow:

# Machine A
git stash export --to-ref refs/stashes/my-stash
git push origin refs/stashes/my-stash

Machine B

git fetch origin '+refs/stashes/:refs/stashes/*' git stash import refs/stashes/my-stash

Older Git versions will not understand the four‑parent commits when they appear in a remote ref. Teams should coordinate upgrades or isolate exported stashes to refs that only compatible clients fetch. Imported stashes are appended to the local list, so any scripts that depend on exact reflog positions will need adjustment.

Reftable advances and Git 3.0 groundwork

Git 2.51 continues the push toward reftable as the default reference backend, and it carries further preparation for SHA‑256 as the default object hash in the planned Git 3.0 era.

For Windows developers, reftable removes a historic pain point. The legacy filesystem‑based ref storage could produce collisions when two refs differed only by case, because Windows and macOS filesystems are case‑insensitive. Reftable stores refs in a binary format that avoids the filesystem entirely, making case‑collisions impossible. It also dramatically improves performance for bulk‑ref updates—common in CI systems and tag‑heavy workflows—thanks to batched writes and automatic compaction.

The SHA‑256 transition is a longer migration that will affect any tooling that hard‑codes SHA‑1 lengths. Administrators should audit scripts, CI pipelines, and backup tools now so they aren’t surprised later.

UX stabilizations and deprecations

  • git switch and git restore graduate from experimental to stable. These commands split git checkout into two clear workflows (branch switching and file restoration) and are now safe for scripting and daily use.
  • git-whatchanged is deprecated and will be removed in Git 3.0. Migrate any existing scripts to git log --raw or equivalent modern invocations.
  • Pathspec and Bloom filter improvements: git log with multiple paths can now sometimes leverage changed‑path Bloom filters, speeding up history queries in large repositories.

Risks and operational advice

The headline performance gains come with engineering trade‑offs that demand careful testing.

  • Temporary disk pressure: Duplicating objects during cruft‑aware repacks consumes extra disk space. Always run repacks with ample free space and during scheduled maintenance.
  • Host I/O load: Repack operations are I/O‑intensive. Production servers should use mirrors or low‑traffic windows.
  • Compatibility of exported stashes: Pushing the new stash commit shapes to a remote that older clients may fetch can cause confusion. Isolate the refs or coordinate upgrades.
  • Tooling assumptions about OIDs: SHA‑256 and reftable migrations will break scripts that assume 40‑character SHA‑1s or that parse .git/refs directories directly.
  • Bitmap/MIDX edge cases: Repositories using alternates, promisor packs, or other exotic object layouts should validate MIDX generation and bitmap writing in a sandbox before enabling repack.MIDXMustContainCruft.

Evaluation checklist for adopters

Individual developers and small teams

  • Upgrade to Git 2.51 to gain stash portability and the stable switch/restore commands.
  • Use git stash export/import only after confirming collaborators are on a compatible version.
  • No immediate maintenance changes required; the defaults are conservative.

Hosting platforms and monorepo operators

  • Mirror a production repository to a test host.
  • Record baseline metrics: MIDX size, repack duration, fetch/pull latency, CPU/memory.
  • Try a repack with --path-walk and compare pack sizes.
  • Experiment with repack.MIDXMustContainCruft in a controlled trial; measure MIDX shrinkage and bitmap generation success.
  • Monitor disk consumption during repacks and keep recent backups.
  • Validate tooling readiness for SHA‑256 and reftable if you plan to test Git 3.0 feature flags.
  • Notify and stage client upgrades to avoid stash‑import or ref‑parsing surprises.

A balanced release for large repos and everyday developers

Git 2.51 is a deeply technical update that will most immediately benefit maintainers of large repositories, but its stash portability and UX promotions make it worthwhile for every Git user. The new repacking behavior resolves a correctness issue while delivering tangible speed and size improvements; path‑walk packing pushes delta compression even further; and the ability to move stashes between machines closes a usability gap that has frustrated developers for years.

Windows teams gain the most from reftable’s case‑insensitivity fix and ref‑update speed, though the server‑side innovations are largely invisible on the desktop. As the march toward Git 3.0 continues, this release exemplifies the project’s ability to introduce ambitious storage‑layer changes while preserving backward compatibility—provided operators test carefully before flipping new switches.