Git 2.54 Ships Experimental 'git history' Command and a Pluggable Object Database, Borrowing Ideas From Jujutsu
Git 2.54, released April 20, introduces a new history-editing command inspired by Jujutsu, config-based hooks, geometric repacking by default, and a pluggable object database built over two years and roughly 400 commits.
Overview
Git 2.54 was released on April 20, 2026, with contributions from more than 137 developers, 66 of them first-time contributors, according to GitHub’s release highlights. The release introduces an experimental git history command for targeted history editing, makes the object database backend pluggable after nearly two years of refactoring, promotes geometric repacking to the default maintenance strategy, and adds configuration-file-based hooks. Several of the changes visibly borrow design ideas from Jujutsu, the alternative Git-compatible version control system.
A New ‘git history’ Command, With Reword and Split
The headline feature is git history, an experimental command designed to make common rewrites less painful than interactive rebase. Two subcommands ship in 2.54. The first, git history reword <commit>, “opens your editor with the specified commit’s message and rewrites it in place, updating any branches that descend from that commit,” as described in GitHub’s release post by Taylor Blau. The second, git history split <commit>, “lets you interactively split a commit into two by selecting which hunks should be carved out into a new parent commit,” using an interface familiar to git add -p users.
GitLab principal engineer Patrick Steinhardt, writing in GitLab’s companion post, is explicit about the inspiration: “We have thus taken inspiration from Jujutsu and have introduced a new git-history(1) command into Git that is the foundation for better history editing.” Future subcommands such as fixup, drop, reorder, and squash are planned, according to the same post.
The current implementation has a deliberate limitation. Per GitHub’s notes, “the history command does not support histories that contain merge commits, and it will refuse to perform any operation that would result in a merge conflict.” Unlike interactive rebase, the command does not touch the working tree or the index, and it can run in bare repositories.
Pluggable Object Database After Two Years of Work
Git 2.54 also lands a long-running internal refactor: the object database backend is now pluggable. Steinhardt frames the scale of the effort in GitLab’s post: “This is the culmination of almost two years of work spanning across almost 400 commits that have been merged upstream.”
The change introduces a function-pointer-based backend for operations such as read_object(), write_object(), and for_each_object(), laying the groundwork for alternative storage formats without changing Git’s user-visible commands. According to GitLab’s post, the abstraction currently supports local workflows but excludes remote operations such as fetch and push, which will follow later.
Config-Based Hooks, Geometric Repacking, and HTTP 429 Retries
Two workflow-level changes stand out for day-to-day users. Hooks can now be defined in Git configuration rather than solely as executable scripts under .git/hooks/. GitHub’s post gives the example syntax [hook "linter"] event = pre-commit command = ~/bin/linter --cpp20, and notes that traditional hook scripts continue to work and execute after config-defined ones.
Maintenance behavior also changes by default. Geometric repacking, which was already available as an option, now runs when users invoke git maintenance run without arguments. As GitHub describes it, “In 2.54, it becomes the default strategy for manual maintenance. That means when you run git maintenance run without specifying a strategy, Git will now use the geometric approach.” GitLab’s post frames the shift similarly, noting that Git is “now using geometric repacking with fine-grained individual maintenance tasks” in place of the older git-gc approach.
On the network side, Git’s HTTP transport has been taught to handle throttling responses more gracefully. Per GitHub’s release notes, “Git’s HTTP transport now handles HTTP 429 ‘Too Many Requests’ responses” by retrying requests, “honoring the server’s Retry-After header when present.” New http.maxRetries and http.maxRetryTime configuration knobs let administrators tune the behavior.
Smaller but Notable Changes
Several smaller improvements round out the release. The experimental git backfill command, used in partial clones, “learned to accept revision and pathspec arguments,” according to GitHub’s notes, which means users can limit blob downloads to a specific range of history or a subset of paths. Repository-structure analysis has also been expanded: GitLab’s post notes that the git repo structure command, introduced in Git 2.52, has been extended further in 2.53 and continues to evolve toward parity with the standalone git-sizer tool.
This release builds on earlier Machine Herald reporting on Git 2.53, which made Rust a default build requirement and is widely seen as a staging ground for a Git 3.0 release later in 2026.
What We Don’t Know
Neither GitHub nor GitLab publishes a firm timeline for when git history will lose its experimental label or when the pluggable object database will be extended to remote operations. The set of additional subcommands planned for git history — fixup, drop, reorder, and squash — is mentioned by GitLab but without specific target versions. Performance figures for geometric repacking versus the legacy gc strategy on large monorepos are also not disclosed in either release post.