The Git project has just rolled out version 2.51, bringing a wave of exciting improvements, smarter defaults, and long-awaited fixes. With contributions from 91 developers (including 21 first-timers), this release not only polishes core Git functionality but also prepares the ground for the much-anticipated Git 3.0.
If you’ve been keeping up since Git 2.50, this update has plenty to offer ranging from faster repository performance to new stash workflows and expanded command stability. Let’s take a guided tour through everything Git 2.51 brings to the table.
Cruft-Free Multi-Pack Indexes: Faster and Leaner Repositories
Git stores everything—blobs, trees, and commits—as “objects.” These live either:
- as loose objects (
$GIT_DIR/objects/...), or - bundled together in packfiles (
$GIT_DIR/objects/pack).
Each pack has its own index. The problem? When a repository grows with many packs, lookup speed slows to O(M*log(N)), where M = number of packs and N = objects in each pack.
To solve this, Git introduced the multi-pack index (MIDX): a single index spanning multiple packfiles. Lookups then drop to O(log(N)), massively improving speed at scale. GitHub relies heavily on MIDX for performance.
But cruft packs—used to hold unreachable objects—caused issues. If an unreachable object later became reachable but lived only in a cruft pack, it wouldn’t have a bitmap entry, making reachability tracking impossible.
Git 2.51 fixes this elegantly:
- During repack, Git now ensures any object that exists only in a cruft pack is duplicated into regular packs.
- This guarantees that non-cruft packs remain closed under reachability.
A new configuration option, repack.MIDXMustContainCruft, enforces this behavior. At GitHub, enabling it delivered impressive results:
- 38% smaller MIDXs
- 35% faster writes
- ~5% faster repository reads
For large repositories, this is a must-try.
Path Walk: Smarter and Smaller Packfiles
Back in Git 2.49, the name-hash v2 algorithm improved delta compression by considering more of the filepath structure rather than just the last 16 characters (an old heuristic from 2006). This reduced the packfile size in many scenarios.
Now, Git 2.51 goes a step further with the path walk approach:
- Instead of walking objects in revision order, Git groups objects by path.
- This ensures deltas are found among related files in the same path.
- It avoids reliance on hashing altogether, delivering even smaller packfiles with competitive performance.
You can enable this with:
git repack --path-walk
For teams managing massive repos, this can mean significant disk savings.
Stash Interchange Format: Finally, Shareable Stashes
Developers’ love git stash for saving uncommitted work. But under the hood, it’s messy:
- Each stash creates three commits (staged changes, unstaged changes, and a merge commit).
- These live in
refs/stash, but only one stash reference exists at a time. - Migrating stashes across machines? Painful.
Git 2.51 introduces a new stash representation that chains stash entries together, each pointing to the previous one. With this log-like model, stashes can now be exported and imported across repositories.
Example workflow:
On one machine:
git stash export --to-ref refs/stashes/my-stash
git push origin refs/stashes/my-stash
On another:
git fetch origin '+refs/stashes/*:refs/stashes/*'
git stash import refs/stashes/my-stash
Stashes are now portable, collaborative, and no longer stuck on a single machine.
Other Noteworthy Improvements
Improved git cat-file
The git cat-file tool prints raw object data. Previously, asking it about a submodule returned missing. Now, in 2.51, it properly identifies submodules with their object ID and type—unlocking new scripting possibilities.
Better Bloom Filter Support
Bloom filters help Git skip irrelevant commits in history searches. Until now, they couldn’t optimize when multiple pathspecs were passed.
With Git 2.51, you can now run:
git log -- path/to/a path/to/b
and still benefit from Bloom filter acceleration.
git switch and git restore Graduated
Introduced in Git 2.23, these commands split git checkout into simpler, more purpose-built alternatives:
git switch→ branch switchinggit restore→ restoring files
After six years of testing, they’re now officially stable and guaranteed compatible with future releases.
Goodbye to git whatchanged
Remember git whatchanged? It’s basically git log --raw. As of 2.51, it’s deprecated and will be removed in Git 3.0.
For now, you can still use it with the flag:
git whatchanged --i-still-use-this
Preparing for Git 3.0: Breaking Changes Ahead
Git 2.51 also gives us a glimpse of what’s coming in Git 3.0:
- Reftable backend will be the new default storage format.
- SHA-256 will replace SHA-1 as the default hashing algorithm for new repositories.
Want an early taste? Build Git with:
make WITH_BREAKING_CHANGES=1
No official release date yet, but the path is clear.
Development Process Updates
Git has long been conservative about adopting new C standards. Since requiring a C99 compiler in 2021, it has slowly integrated features. With 2.51:
- The
boolkeyword is now fully adopted across the codebase. - The team is documenting which C99 features are in use and which aren’t.
On the contribution side, Git now aligns with the Linux kernel by allowing patches under pseudonyms, rather than requiring legal names. This opens the door to broader contributions.
Conclusion
Git 2.51 is more than just another incremental release—it’s a performance upgrade, a usability improvement, and a preview of Git’s future. From cruft-free MIDXs and path walk compression to stash interchange and new command stability, this release modernizes workflows for developers everywhere. As Git 3.0 looms with breaking changes and new defaults, now is the time to explore these features and prepare your repositories for what’s next.
Dive into the full release notes here for every detail.
If you are hearing about Git for the first time read this.
