Git 2.54 simplifies history rewriting with new tools

Git 2.54 arrived this month, bringing targeted improvements to the distributed version control system that powers millions of software projects. Developed by over 137 contributors—66 of them new to the project—the release builds on the foundations of Git 2.53 to deliver features that enhance usability, automation, and collaboration. For teams managing multiple repositories, the most notable additions are two experimental commands designed for lightweight history editing and a new way to define and manage Git hooks without scripting.

Streamlined history edits with git history

Git’s git rebase -i remains the go-to tool for complex history rewrites, but its power comes with overhead. For simple adjustments—like correcting a commit message three steps back or splitting a single commit into two—an interactive rebase often feels excessive. Git 2.54 addresses this with git history, a new experimental command tailored for these smaller, targeted edits.

The command currently supports two operations: reword and split. The git history reword <commit> command opens your default editor with the specified commit’s message, allowing you to make changes that propagate to all branches descending from that commit. Unlike rebases, it avoids modifying your working directory or index, and it even works in bare repositories—ideal for CI pipelines.

For splitting a commit, git history split <commit> offers an interactive interface similar to git add -p. You select which hunks to extract into a new parent commit, and Git rewrites the history to reflect the change while preserving descendent branches. This approach minimizes manual intervention and reduces the risk of conflicts.

Both features are intentionally limited to non-merge commits and conflict-free operations, ensuring they remain simple and reliable for routine adjustments. Behind the scenes, the command leverages git replay’s core machinery, which has been extracted into a reusable library. This design choice enables scripting and automation without touching the working tree.

As an experimental feature, git history may evolve in future releases. Early adopters can explore it today by upgrading to Git 2.54.

Centralized hooks via configuration files

Git hooks have traditionally been constrained to executable scripts stored in a repository’s .git/hooks directory. This limitation forced teams to either duplicate scripts across repositories or rely on symbolic links—neither of which scales well. Git 2.54 introduces a configuration-based alternative, allowing hooks to be defined in Git config files instead.

A hook can now be declared directly in your ~/.gitconfig, system-wide /etc/gitconfig, or a repository’s local config using a simple syntax:

[hook "linter"]
    event = pre-commit
    command = ~/bin/lint-tool --strict

This approach eliminates the need to maintain duplicate scripts. Multiple hooks can even be attached to the same event. For example, you could run a static analyzer and a secrets scanner before each commit:

[hook "analyzer"]
    event = pre-commit
    command = ~/bin/static-analysis --cpp20

[hook "secrets"]
    event = pre-commit
    command = ~/bin/secrets-scanner

Git executes these hooks in the order they appear in the configuration, with traditional .git/hooks scripts running last. This ensures backward compatibility while enabling more flexible workflows.

Administrators can also disable specific hooks per-repository by setting hook.<name>.enabled = false, making it easier to manage exceptions without altering the central configuration. Under the hood, Git has modernized its internal hook handling by migrating legacy hooks—such as pre-push and post-rewrite—to the new API, ensuring consistent behavior across all hook types.

What’s next for Git users?

Git 2.54’s experimental git history and configuration-based hooks represent a shift toward more intuitive, scalable workflows. While git history is still in its early stages, its focus on simplicity could make history edits more accessible to developers who avoid complex rebases. Meanwhile, the new hook system simplifies the management of pre-commit checks, linting, and other automation across teams.

For users eager to test these changes, upgrading to Git 2.54 is straightforward. As the project continues to evolve, expect further refinements to these features—especially as feedback from the community shapes their development. The next release may bring additional experimental commands or expanded hook capabilities, reinforcing Git’s role not just as a version control system, but as a platform for seamless collaboration.