Git 2.55: Rust Now Default, git history fixup Arrives

Git 2.55 shipped on June 29, and the change most teams will feel first is quiet and breaking: Rust is now enabled by default when compiling Git from source. If your CI builds Git from a tarball or a source clone, you need a Rust toolchain or an explicit opt-out before the build starts failing. Alongside that, the release delivers git history fixup — a single command that replaces the most dreaded interactive rebase workflow — plus incremental multi-pack index writing for large repos and a long-overdue built-in fsmonitor daemon for Linux.

Rust Is Now a Build Requirement (Unless You Say Otherwise)

Since Git 2.38, Rust code has lived in the repository — but it was optional and compiled only when you asked for it. Git 2.55 reverses that default. Rust is now compiled in unless you explicitly disable it with make NO_RUST=1 (Makefile builds) or meson -Drust=disabled (Meson builds).

If you install Git through Homebrew, apt, pacman, winget, or any binary distribution channel, you are not affected. Packagers handle the Rust toolchain; the compiled binary lands on your machine without you touching it. The impact is narrow but consequential: CI pipelines, container images, and distribution build systems that compile Git from source will fail unless a Rust toolchain is present.

This is not the end state. Git 3.0, targeted for late 2026, removes the NO_RUST escape hatch entirely. Rust will be a mandatory build dependency with no opt-out. If you are compiling Git from source today, the path forward is clear: add rustup to your build environment now, or set NO_RUST=1 to buy time until you are ready.

The Rust investment is not cosmetic. Git’s memory safety track record is mixed — long-standing bugs in path handling and pack code have burned the project. Adding Rust incrementally for performance-critical and safety-sensitive components is the same bet the Linux kernel and curl made, and it is paying off in both cases.

# Opt out of Rust in Git 2.55 (temporary — removed in Git 3.0)
make NO_RUST=1

# Or with Meson
meson -Drust=disabled builddir

git history fixup: One Command Instead of a Rebase Session

Git 2.54 introduced the experimental git history command with stacked branch awareness — we covered it here. Git 2.55 adds its most useful subcommand: fixup. Stage your changes, point it at the commit you want to amend, and you are done.

git add auth.py
git history fixup abc123

Under the hood, Git performs a three-way merge between the HEAD commit, the target commit, and the staged tree, then replays every descendant commit on top of the rewritten result. The commit message and authorship are preserved unless you pass --reedit-message. Importantly, git history fixup knows about your local branch topology: all branches that contain the target commit are automatically rebased.

The old workflow — git commit --fixup, then git rebase -i --autosquash — worked, but it required navigating an interactive editor designed in 2007. git history fixup reduces that to two commands. For teams using stacked branches, it also eliminates the manual step of tracking which branches need rebasing after a history rewrite.

The command is still experimental in 2.55, so run with --dry-run before applying to anything you care about. Conflicts abort rather than dropping you into a resolution session, so there is no silent data loss risk.

Incremental MIDX: Large Repo Maintenance Gets Smarter

Multi-Pack Index (MIDX) files have indexed Git’s pack objects since 2.21. The problem was that every maintenance run rewrote the entire MIDX even if only a few new packs had arrived. Git 2.55 fixes this with layered MIDX writing. New packs get a new layer appended to the existing chain; old layers are not touched. Geometric repacking keeps the chain from growing unbounded — smaller, newer layers merge when the chain drifts from a logarithmic shape.

# Incremental MIDX repack with geometric compaction
git repack --write-midx=incremental --geometric=2 -d

For monorepos and repositories that receive a constant stream of pushes, routine maintenance is now proportional to new data rather than total repository size. That is a meaningful difference at scale.

Linux Gets a Built-in fsmonitor

The fsmonitor daemon — which watches the working tree for changes and lets git status skip the full filesystem scan — has been available on macOS via FSEvents and on Windows via ReadDirectoryChangesW for years. Linux developers have been waiting. Git 2.55 adds support through the kernel’s inotify subsystem.

git config core.fsmonitor true
git fsmonitor--daemon start

On large repos, the difference in git status latency is substantial. One caveat: inotify requires one watch per directory, and the default kernel limit is 8,192. Large repos will hit this ceiling. Raise it with sudo sysctl -w fs.inotify.max_user_watches=524288 and persist the change in /etc/sysctl.conf.

Also in 2.55

Config-based hooks can now declare hook.<name>.parallel = true to run concurrently with other hooks on the same event. Independent pre-push hooks for linting and tests no longer have to block each other. Control concurrency with hook.jobs. Some hooks that share resources — like prepare-commit-msg — cannot be parallelized and are exempt.

git push now accepts a remote group name. Configure a group with git config remotes.mirrors "github gitlab backup", then run git push mirrors to push to all three at once. Each remote gets an independent subprocess with its own push mapping. The --atomic flag is not supported for group pushes.

A quiet security improvement: sideband progress messages from remote servers are now sanitized by default. Control characters that could move the cursor or erase terminal text are masked while ANSI color sequences pass through. This removes a low-severity but real attack surface where a malicious server could manipulate your terminal output during a fetch or push.

What to Do Now

1. If you build Git from source in CI: audit your Dockerfiles and build scripts. Add a Rust toolchain, or set NO_RUST=1 explicitly to keep building without one. Git 3.0 removes that option — plan the migration now.
2. If you use stacked branches: install 2.55 and try git history fixup on your next fixup commit. Use --dry-run first. The ergonomics are already better than the rebase-autosquash dance.
3. If you maintain a large repo on Linux: enable fsmonitor and switch to incremental MIDX repacking. Both changes are transparent to contributors and only affect local maintenance performance.

Git 2.55 is available now. The GitHub Blog highlights post and the GitLab release breakdown cover the full change log. The LWN.net preview has the most complete technical discussion of the Rust and MIDX changes ahead of the stable release.