Git 2.55 arrived this week carrying more than a hundred contributors’ worth of changes. Thirty-three of those contributors submitted patches for the first time. The release marks a deliberate step in the project’s long-planned move toward Rust while delivering practical gains for developers who manage large codebases or wrestle with commit history on a daily basis.
Phoronix reported that Rust support now builds by default. Packagers and developers who compile from source will encounter Rust as a requirement unless they explicitly pass the NO_RUST flag. This matches the roadmap laid out in Git’s own documentation. The project began introducing Rust code in version 2.49. It remained optional through early testing phases. Now both the Meson and Makefile build systems enable it automatically.
But the Rust transition won’t become mandatory until Git 3.0. The final release before that major version will receive long-term support. Important bug fixes continue for at least four additional release cycles. Security updates run for six cycles. Maintainers plan to hand the long-term release over to distributors if further extension becomes necessary. They will study the effect on downstream distributions before flipping the switch. The evaluation considers how difficult it has proven to keep Rust optional.
So the current change affects builders more than end users. Yet it signals clear intent. Rust code already appears in libgit bindings, a varint subsystem, and an ObjectID type that handles both SHA-1 and SHA-256. These pieces test interoperability between the established C implementation and newer Rust components.
One of the most immediately useful additions targets developers who amend earlier commits. The experimental git history command, introduced in 2.54, now includes a fixup subcommand. Run git history fixup after staging changes. The tool folds those modifications into the target commit, replays descendant commits, and updates every local branch that contains the rewritten commit.
GitLab’s engineering blog explained the advantage for stacked branches common in many workflows. No interactive rebase. No manual cherry-picking. The operation remains conservative. It refuses to run without a working tree and aborts on conflicts. Bare repositories stay unsupported while the feature matures. Still, the command already removes friction for teams that refine history frequently.
Repository maintenance also received attention. The GitHub Blog highlighted incremental multi-pack index support. The command git repack --write-midx=incremental writes new MIDX layers without rebuilding the entire index chain. Combine it with geometric repacking using --geometric=2 and the repack.midxSplitFactor configuration. The approach keeps the number of layers logarithmic. It prefers to rewrite newer, smaller packs first. Large repositories that receive steady updates benefit most. Full MIDX rewrites become rarer.
Performance numbers shared in the GitHub overview speak clearly. Bitmap generation time dropped from 612 seconds to 294 seconds in one large repository through better reachability algorithms, caching, and reduced tree recursion. Pseudo-merge bitmaps now deliver roughly 20 times faster object traversal with lower generation overhead. Path-walk packing, when paired with partial-clone filters such as blob:none or blob:limit, produced packs about 16 percent smaller in tests on the Git repository itself. The smaller size comes at the cost of slower delta computation, a trade-off maintainers expect many users will accept.
Linux users gain a built-in fsmonitor daemon. Previous versions required third-party tools on that platform. The new inotify-based implementation needs no special privileges for local filesystems. Network mounts require explicit opt-in. The daemon dramatically speeds up git status in large monorepos by tracking only changed files instead of scanning everything. Administrators may need to raise the fs.inotify.max_user_watches limit on systems with enormous trees.
Remote handling grew more convenient. Remote groups have existed for fetch operations for years. Git 2.55 extends the same configuration to push. Define git config remotes.publish "github gitlab mirror" then run git push publish main. The operation pushes to each remote in sequence. Atomic pushes across remotes remain unavailable. Even so, the feature eliminates the need for custom aliases or shell scripts in many mirroring scenarios.
Visualization of complex histories also improved. The --graph-lane-limit= option for git log --graph caps the number of displayed lanes. Excess branches collapse into a tilde character. Wide repositories become readable without losing the overall shape of the graph.
Scripting received a small but welcome tool. git format-rev reads revision specifications from standard input and formats them according to a given string. Pipeline enthusiasts can now transform commit lists without repeated calls to other Git commands.
Hook execution gained parallelism. Compatible hooks, those that do not depend on the index or working tree state, can run concurrently when hook. is set to true. Administrators control concurrency through hook.jobs, per-hook settings, or the -j command-line flag. Index-dependent hooks continue to run serially to avoid race conditions.
Partial clones see faster git grep and git cherry behavior. The client now batches blob downloads more efficiently when those objects are missing due to filters. Searches across historical revisions that previously triggered many round trips complete with less latency.
Checkout with merge conflict handling also changed. The -m option to git checkout now stashes conflicted changes automatically. Developers can resolve or reapply the stash later without losing work.
Fetch negotiation offers new controls. Administrators can specify which references participate in the “have” lines sent during negotiation using include and restrict options. Equivalent configuration keys exist under the remote section. These settings help fine-tune bandwidth usage in repositories with complex ref hierarchies.
Sideband progress reporting cleans up output. Control characters that previously produced visual artifacts in terminals are masked while colors and legitimate progress indicators remain intact.
git rev-list learned --max-count-oldest. When combined with a range and reverse ordering, it selects the oldest commits rather than the newest. The option simplifies certain log-analysis scripts.
These changes arrive against a backdrop of steady maturation. Git’s maintainers continue to balance new language adoption with stability for the massive installed base. The Rust pieces still sit behind an escape hatch. Yet the default-on status in 2.55 forces distributors to confront the dependency earlier than many expected. Some will welcome the memory-safety promises. Others will watch the long-term support plans closely.
Developers working on massive monorepositories will notice the fsmonitor and repack improvements first. Teams that maintain clean histories will appreciate the fixup command once it leaves experimental status. Infrastructure teams responsible for build pipelines must now ensure Rust toolchains sit on their compile hosts or consciously disable the feature.
The release notes contain far more than these highlights. Bug fixes, documentation updates, and smaller optimizations fill the remainder. Yet the visible themes stand out. Better history tools. Smarter maintenance for large repositories. Incremental movement toward modern implementation languages. And a continued focus on performance where it matters most to daily users.
Git has never stood still. Version 2.55 simply continues that tradition with changes that feel both evolutionary and immediately practical. The Rust question looms larger on the horizon. For now, the new commands and optimizations give teams concrete reasons to upgrade.
WebProNews is an iEntry Publication