By Git 2.55 shipped on June 29 and buried the lead: Rust is now on by default. Until this release, you had to opt in with WITH_RUST=1. Now you opt out with NO_RUST=1. If you maintain a CI pipeline that compiles Git from source and you don’t know that, your next container rebuild is going to surprise you. Beyond the Rust change, this release adds git history fixup, parallel hook execution, and Linux fsmonitor support via inotify — each one worth understanding.
Rust Is On by Default — and Git 3.0 Will Make It Mandatory
The rename from WITH_RUST to NO_RUST is a small textual change with a large operational meaning. Any build pipeline that compiles Git without explicitly suppressing Rust will now require a working Rust toolchain. That includes Docker images built on top of distro base images, embedded toolchains, and any custom Git packaging maintained by infrastructure teams.
The opt-out paths:
# Makefile builds
make NO_RUST=1
# Meson builds
meson configure -Drust=disabledIf you use pre-built packages from your distribution, you likely won’t notice anything — package maintainers handle this at the spec level. But if you roll your own Git builds, audit your pipelines now. Git 3.0, targeted for late 2026, will remove the NO_RUST option entirely. Rust will be mandatory, full stop.
The community reaction has been predictable. The Libre-WD40 project — led by the developer behind the XLibre Xorg fork — released a de-Rusted Git 2.55 within days of the official release. The name is a pun: WD-40 removes rust. This is technically interesting as a demonstration of what open source allows, but it is not a credible long-term alternative to the official Git project. If your organization has genuine concerns about the Rust toolchain dependency, the NO_RUST flag exists for a reason. Use it while it lasts.
git history fixup: One Command Instead of Two
The git history command landed experimentally in Git 2.54. In 2.55, it gains a fixup subcommand that collapses the traditional two-step fixup workflow into one.
Old workflow: git commit followed by git rebase interactive autosquash.
New workflow: Stage your changes, then run git history fixup with the target commit SHA. Done.
The command folds your staged changes into the target commit and replays all descendant commits on top automatically. Crucially, it also updates every local branch that contains the fixed-up commit — which makes it genuinely useful for stacked branch workflows where a single fixup would otherwise require rebasing multiple branches by hand.
Important caveats: git history fixup is still experimental. It requires a working tree (no bare repos), and it aborts cleanly on merge conflicts rather than leaving you in the middle of a stateful rewrite. That abort behavior is actually safer than interactive rebase, which can leave you in a detached HEAD state mid-rebase.
Parallel Hooks: Lint and Test at the Same Time
Config-based hooks landed in Git 2.54. Git 2.55 adds opt-in parallel execution. If you have independent pre-push hooks — a linter and a unit test runner, for example — they can now run simultaneously. Configure parallel = true on any hook and set jobs = -1 to use all CPU cores.
Not all hooks can be parallelized — pre-commit and prepare-commit-msg are explicitly excluded because they share the commit message buffer. But for pre-push and post-merge hooks that do not share resources, this is a straightforward performance win with no code changes required.
Linux fsmonitor: git status Gets Fast on Large Repos
The built-in fsmonitor daemon has existed in Git for several releases, but only for macOS and Windows. Git 2.55 adds Linux support using the kernel’s inotify subsystem.
Enable it with two commands: git config core.fsmonitor true, then git fsmonitor–daemon start. The daemon watches the filesystem for changes instead of walking the directory tree on every command. In one benchmark cited in the official Git 2.55 release highlights, bitmap generation dropped from 612 seconds to 294 seconds. On a repository with 500,000 files, git status goes from several seconds to nearly instant after the daemon warms up.
One caveat that will catch Linux monorepo teams: inotify’s default per-user watch limit is 8,192. Large repositories will hit this ceiling immediately. You can bump it via sysctl by setting fs.inotify.max_user_watches to 524288 — add it to /etc/sysctl.conf to make it permanent.
What Else Changed
Git 2.55 also ships incremental MIDX repacking, which appends new layers to the multi-pack index instead of rewriting the whole thing — important for Git hosting providers and large monorepos. Sparse checkout performance improved by roughly 50% for repositories where you check out a small fraction of a large tree. These matter at scale but are unlikely to affect most development workflows directly.
Upgrade Now or Prepare Your Opt-Out
Git 2.55 is a release that requires a decision. If you build Git from source: add Rust to your toolchain or set NO_RUST=1 now, before 3.0 makes that choice for you. If you use packaged Git: enable fsmonitor on Linux and try git history fixup in your next refactor session. The parallel hooks configuration takes five minutes to set up and will save time on every push.
Rust in Git is not a debate anymore. It is the direction. The only remaining question is whether you get ahead of it now or scramble when 3.0 drops.
