Git 2.55 dropped on June 29. Most of the headlines will be about subtle infrastructure work. That is fine. The interesting changes are all the kind of thing you only notice when your repo has hundreds of thousands of objects.
The release includes contributions from over 100 people, 33 of them first-time contributors. If you only update Git once a year, this is the year to do it.
The big win is incremental MIDX repacking
If you have ever run git gc on a multi-gigabyte monorepo and gone to make coffee, you have felt the pain Git 2.55 is trying to fix.
Git stores commits, trees, and blobs as objects. Those objects usually live in compressed packfiles. A packfile has a corresponding pack index that lets Git find any object quickly. Big repos accumulate many packfiles over time. A multi-pack index (MIDX) gives Git one index across many packs, which is faster.
Git 2.47 introduced the incremental MIDX format. It stores the MIDX as a chain of layers instead of one giant file. New packs get added as a new layer without rewriting the whole index. That was already a big deal for huge repos.
What 2.55 adds is the ability to write those incremental MIDX chains directly during repack:
git repack --write-midx=incremental
Used alone, this is append-only. Each run adds a layer. Combined with geometric repacking, you get the smart behavior:
git repack --write-midx=incremental --geometric=2 -d
Now Git creates a new tip layer, then decides whether adjacent layers should be compacted together. If accumulated newer layers grow large enough relative to the next older layer, Git merges them into a single replacement layer. Otherwise, older layers stay untouched.
The result is the same outcome as a full repack but with a fraction of the metadata rewrite work. For monorepos and long-lived projects, this can turn an overnight maintenance job into a few minutes.
Reftable gets more practical
Reftable is Git's newer reference storage backend, designed to replace the loose refs plus packed-refs model. It scales better to repositories with millions of refs, which is the reality for any large monorepo or forges running millions of repos.
Git 2.55 keeps tightening the reftable implementation. The release notes cover additional fixes around ref deletion, reflog handling, and consistency checks. None of it is flashy. All of it matters if you actually run Git at scale.
The takeaway is that reftable is moving from "interesting alternative" to "default recommendation for big repos." If you maintain infrastructure for a Git host, the upgrade is worth planning for.
Other changes worth scanning
A few smaller items are still useful:
- New
git diffoptions for cleaner merge-base handling - Improved handling of sparse-checkout interactions with partial clone
- Performance work on
git logfor repos with very large history - Continued cleanups to the credential helper protocol
- Various fixes for Windows path handling
Nothing revolutionary on its own. Together they make Git feel less fragile on awkward repos and weird paths.
Who actually notices this
Honestly, most developers will not notice. If your repo fits in a few thousand commits and a couple of gigabytes, Git 2.55 will behave like Git 2.54. That is the goal.
The people who will notice are platform engineers running Git hosts, monorepo maintainers running nightly repacks, and anyone working with vendored dependencies that bloat packfiles. For them, the incremental MIDX work alone can save hours of CI time per week.
If you are on a Git host like GitHub or GitLab, you do not need to do anything. They manage their own Git. But it is worth knowing that the upstream improvements are landing, because they tend to make their way into hosted Git products over the next few quarters.
How to upgrade
On most systems:
git --version
git update-git-for-windows # Windows
brew upgrade git # macOS with Homebrew
sudo apt upgrade git # Ubuntu/Debian
On production CI runners, pin the version, run the new release on a non-critical job for a few days, then roll out.
One thing worth doing after the upgrade: check your gc.auto settings. If you have aggressive auto-gc, the new incremental MIDX behavior kicks in automatically. If you have aggressive manual repacks scheduled, you may want to revisit them. The default settings are usually fine, but monorepo maintainers tend to tune these by hand.
The other thing worth doing: take a baseline. Run a git count-objects -v and a git maintenance run before and after the upgrade on a known-large repo. The diff tells you whether the incremental MIDX is actually working for your workload. Numbers beat feelings.
Git 2.55 is not a release that breaks your day. It is a release that quietly removes a few sharp edges you have probably learned to live with.
Sources
- Highlights from Git 2.55 (GitHub Blog, June 29, 2026)
- Git 2.55 release notes (Git project)
