Git 2.51 lands with cruft-less MIDX, path-walk packs, stash import/export and 3.0 groundwork

Home » Python » Git 2.51 lands with cruft-less MIDX, path-walk packs, stash import/export and 3.0 groundwork

Git 2.51 is out, bringing a broad set of improvements from more than 91 contributors (including 21 first-timers) and a continued push to modernize the tool without disrupting established workflows.

This release focuses on practical upgrades—from storage and packing to usability and security posture—while laying the tracks for changes slated for Git 3.0.

Cruft-free multi-pack indexes

Git stores data as objects (blobs, trees, commits) either loosely or inside packfiles, with pack indexes mapping hashes to offsets. Multi-pack indexes (MIDX) let Git index objects across many packs, turning many lookups into a single O(log N) search, and they also power reachability bitmaps for fast containment checks.

The wrinkle has been cruft packs, where unreachable objects live outside the MIDX. If an object that was once unreachable later becomes reachable from a bitmapped commit but exists only in a cruft pack, it has no bit position—blocking bitmap generation.

Git 2.51 changes repack behavior so that when generating new non-cruft packs, it duplicates objects (and their ancestors) whose only other copy resides in a cruft pack. Repeating this ensures the non-cruft set is closed under reachability, enabling consistent bitmap coverage.

A new config makes this easy: repack.MIDXMustContainCruft uses the updated repack logic to keep cruft packs outside the MIDX. In large-scale use, MIDX files shrank by about 38%, were written ~35% faster, and improved read performance by roughly 5%.

Smaller packs with path walk

Git 2.49 introduced a better name-hash for ordering objects during delta selection, reducing reliance on the last 16 path characters and considering directory structure for smarter pairing.

Git 2.51 goes further with a new “path walk” collection mode for repacking. Instead of emitting objects strictly in revision order, Git groups and emits all objects for a given path together, bypassing the need for name-hash heuristics.

The result is leaner packfiles with improved delta opportunities among same-path objects and timings that are competitive with the classic traversal. You can try it with the new --path-walk option when repacking.

Stash interchange format

If you use git stash frequently, you know it traditionally models each stash as three commits (staged, unstaged, and a synthetic parent tying them together) stored under refs/stash, making cross-machine migration awkward.

Git 2.51 adds a chained representation where each stash entry includes additional parentage linking to the previous stash entry, forming a linear history that’s easier to move and manage.

New subcommands unlock portability: you can export stashes into a single reference and push/pull them like any branch or tag, then import on another machine.

Example workflow:

$ git stash export --to-ref refs/stashes/my-stash
$ git push origin refs/stashes/my-stash

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

Performance notes for large repositories

Reference updates scale better in repositories with very large numbers of refs, thanks to batched updates that reduce transactional overhead. In scenarios with ~10,000 refs, reported gains include dramatic speedups—particularly with the reftable backend—on operations like fetch and push.

Tooling and UX polish

• git cat-file is more informative for submodule paths in --batch-check mode, reporting a submodule entry instead of just “missing”.
• Changed-path Bloom filters now help with multiple pathspecs (e.g., git log -- a b), expanding the optimization’s reach.
• git switch and git restore are stable and no longer considered experimental, cementing their roles as clearer alternatives to git checkout.
• git whatchanged is deprecated and slated for removal in Git 3.0; it remains available behind --i-still-use-this.
• git for-each-ref adds pagination via --start-after, improving ref listing in very large repositories.
• Merging gets a tidier summary with --compact-summary for git merge and git pull.

Toward Git 3.0: security and storage defaults

The project continues its SHA-256 transition. While new repositories are still SHA-1 by default today, more internals and transports in 2.51 understand SHA-256, easing experimentation and compatibility testing.

Reftable is on track to be the default reference backend in Git 3.0, addressing case sensitivity and Unicode pitfalls on Windows/macOS, enabling atomic ref transactions, and benefiting from geometric compaction and prefix compression.

Want a preview of future defaults? You can build Git with WITH_BREAKING_CHANGES to test the upcoming baseline (e.g., SHA-256 and reftable defaults) before the 3.0 release.

Developer process and standards

C99 usage expands: the codebase now broadly permits the bool keyword, and the project documents which C99 features are adopted or under evaluation, balancing modern language features with portability.

Contribution guidelines evolve to allow submissions under identities other than a contributor’s legal name, aligning more closely with the Linux kernel’s approach and lowering barriers for participation.

Git 2.51 blends concrete wins—like cruft-less MIDX, path-walk packs, stash import/export, and large-repo performance boosts—with steady progress toward stronger cryptography and modern storage defaults, delivered by a diverse community of maintainers and new contributors alike.