Git 2.55 builds with Rust support enabled by default for the first time

Git 2.55 shipped on June 29. The headline change is at build time: for the first time, the release compiles with its Rust code turned on by default.

That needs care, because it is easy to overstate. Git is still a C project. The Rust support has been in the tree as an opt-in build flag for a while, something you had to ask for at compile time. In 2.55 the default flips: the build now includes the Rust components unless you explicitly pass NO_RUST. Nothing about how you use Git changes, no command behaves differently, and you can still turn it off. What changed is which way the switch points when a distribution or a developer builds Git from source without touching it.

The maintainers have been clear about the trajectory without committing to a date. The plan, as Phoronix noted from the release, is that Rust stays optional in 2.55 and could become mandatory at Git 3.0 or some later point. Enabling it by default is the intermediate step: it gets the Rust build path exercised across every distribution's build farm and every from-source install, which surfaces packaging and toolchain problems now, while opting out is still a single flag, rather than at the point where opting out is no longer allowed. It is a conservative rollout for a project that has reason to be conservative.

git history fixup

The change most people will actually type is git history fixup. It targets a specific, common annoyance: you are polishing a series of commits, and you realize a change in your working tree belongs in an earlier commit, not at the tip.

The old way spells out the mechanism instead of the intent:

git commit --fixup=<commit>
git rebase --autosquash <commit>^

The new way states what you want:

git history fixup <commit>

It takes whatever is staged in your index, folds it into the target commit, and replays the descendant commits on top. The target keeps its original message and authorship unless you pass --reedit-message. It is deliberately cautious: it reads from the index, so it needs a working tree and will not run in a bare repository, and if applying the staged change would cause a conflict it aborts rather than dropping you into a half-finished rewrite. The broader git history command it hangs off of, introduced in 2.54, is still marked experimental, so treat this as a preview of the ergonomics, not a settled interface.

The parts that make big repositories cheaper to maintain

Most of the rest of the release is plumbing, and the theme is doing less work during routine maintenance on large repositories.

The largest piece extends incremental multi-pack indexes. Git stores objects in packfiles, and a multi-pack index (MIDX) is a single lookup table across many packs. The problem with a single-file MIDX is that any update rewrites a file covering every pack, which is expensive once a repository is large. Incremental MIDXs store the index as a chain of layers instead, so a maintenance run can append a layer for new packs without rewriting the whole thing. In 2.55, git repack --write-midx=incremental writes those chains directly, and combined with --geometric=2 -d it decides when to compact adjacent layers, governed by repack.midxSplitFactor and repack.midxNewLayerThreshold. The point is to keep the number of layers logarithmic in the object count so the chain does not itself become the maintenance burden.

Reachability bitmap generation also got faster. These are the structures Git uses to answer "what is reachable from here" without walking the whole graph, and building them is part of maintenance. By skipping unnecessary tree recursion, reusing computed bitmaps, and caching object positions, the patch series cut bitmap generation in one large repository from about 612 seconds to about 294 seconds, per the benchmarks in the series. That is a specific repository and a specific workload, not a universal number, but it is roughly halving a step that runs on every maintenance pass.

A few smaller changes are worth knowing:

• Configured hooks can now run in parallel. If independent hooks like a linter and a unit-test pre-commit both set hook.<name>.parallel = true, Git runs them at once; hooks that inspect shared state still run serially.
• The built-in filesystem monitor, which speeds up git status by asking a daemon what changed instead of scanning the tree, now works on Linux using inotify. It was previously macOS and Windows only. Very large repositories may need to raise fs.inotify.max_user_watches.
• Git now masks most terminal control characters in the remote: sideband output a server sends during fetch and push, while still allowing color sequences. Before this, a server could push cursor-moving or text-erasing escape sequences straight to your terminal.
• git push can now target a remote group configured with remotes.<name>, pushing to each remote in sequence, the same shorthand git fetch already had.

The release came together with over 100 contributors, 33 of them new, according to GitHub's writeup. None of this is going to change how the tool feels day to day. The Rust default is the part that will matter later, and 2.55 is where the groundwork gets laid rather than where anything is forced.