Git 2.55 Adds a 'git history fixup' Command, Brings the FSMonitor Daemon to Linux, and Lets git push Target Remote Groups
Released June 29, the update extends the experimental git history command, adds inotify-based filesystem monitoring on Linux, and lets git push write to a group of remotes at once.
Overview
The Git project released Git 2.55 on June 29, 2026, with features and bug fixes from over 100 contributors, 33 of them new, according to GitHub’s release highlights. The release extends the experimental git history command with a fixup subcommand, brings Git’s built-in filesystem monitor daemon to Linux, and lets git push target a group of remotes using the same shorthand previously reserved for git fetch.
What We Know
A ‘fixup’ subcommand for git history
Git 2.55 “builds on the experimental git history command by adding a new fixup subcommand,” which “applies the changes currently staged in the index to an earlier commit,” as described in GitHub’s release post. The command is invoked as git history fixup <commit>. After folding the staged changes into the target commit, Git “folds it into the original recipe commit and replays the descendant commits on top,” per the same post.
The git history command itself arrived as an experimental feature in Git 2.54, where it shipped reword and split subcommands aimed at making common history rewrites less painful than interactive rebase, as previously reported. GitLab’s engineering blog notes that the new subcommand “takes the staged changes and amends them into the given commit” and that “all other local branches that contain the fixed-up commit are updated as well.” Linuxiac describes it as a “new experimental git history fixup <commit> command, which allows users to apply staged changes directly to an earlier commit and replay subsequent commits on top.”
Filesystem monitoring comes to Linux
Git’s built-in FSMonitor daemon, which lets large repositories avoid scanning the entire working tree on every command, now runs on Linux. “Until now, that built-in daemon was available only on macOS and Windows. Git 2.55 adds support for Linux, where the implementation uses inotify,” according to GitHub. GitLab confirms the same approach, noting that “support for Linux has been added” and that “inotify(7) is used” to achieve it.
Linuxiac frames the daemon as “the most notable feature” for Linux users and says it “is expected to accelerate commands such as git status in large repositories.”
git push gains remote groups
Remote groups — a configured, whitespace-separated list of remotes referenced by a single name — have long been usable with git fetch. Git 2.55 extends the same shorthand to git push. “Remote groups have long been available to git fetch, where a group is configured with remotes.<name> as a whitespace-separated list of remotes. Git 2.55 lets git push use the same shorthand,” GitHub explains, giving the example of configuring git config remotes.publish "github gitlab mirror" and then running git push publish main. GitLab summarizes the change as closing a gap so that “git-push(1) now accepts a remote group too.”
Other changes
Git 2.55 also adds a --graph-lane-limit=<n> option to git log --graph and related commands; “lanes beyond the limit are replaced with ~,” according to GitHub.
On the build side, the release continues Git’s gradual adoption of Rust. “With this v2.55 release the Rust compiler is required unless you explicitly disable it in the build system,” GitLab reports, with Makefile builds able to opt out via make NO_RUST=YesPlease. GitLab traces the timeline back: “In November 2025, in Git 2.52, the first Rust production code was introduced into Git,” with a Rust implementation of the varint subsystem following. The project had already moved to default-enable Rust support in both build systems in Git 2.53, as previously reported.
What We Don’t Know
Neither GitHub nor GitLab sets a date for when the git history command will lose its experimental label, nor do the release posts publish benchmark figures quantifying the speedup the Linux FSMonitor daemon delivers on specific repositories. The posts do not specify when, or whether, Rust will become a non-optional dependency that can no longer be disabled at build time.