Fixing an old commit message in Git, using traditional tools, often requires more steps than necessary: interactive rebase, editing the todo list, selecting the right commit, closing the rebase. It works, but it’s a mechanism designed for broader rewrites. In the post about Git 2.54, GitHub highlights a new experimental command, git history, built specifically for targeted rewrites; the same article also covers features introduced in 2.53.

git history: less friction for targeted rewrites

The new experimental command git history is designed for rewriting history in specific cases and currently exposes two operations: reword and split. The official documentation explicitly presents it as an experimental history rewriting command, not as a general replacement for git rebase.

git history reword <commit> opens your editor with the message of the specified commit and rewrites it while leaving everything else unchanged. By default it updates local branches pointing to commits descended from the rewritten one; alternatively it can update only HEAD. Unlike git rebase, it doesn’t touch the index or working tree, and can operate on bare repositories.

git history split <commit> lets you break a commit into two by interactively choosing which hunks to move into a new parent commit. The interface mirrors git add -p, and the documentation also allows limiting the operation to a pathspec.

The limitations are intentional. git history doesn’t yet work on histories containing merges and refuses operations that would create conflicts. It’s a tool for predictable, focused interventions, not for complex or open-ended rewrites.

Hooks defined in configuration files

One of Git 2.54’s most interesting additions is the ability to define hooks directly in configuration files, rather than relying solely on scripts in the traditional hooks directory. This lets you place hooks in your ~/.gitconfig file, in system configuration, or in the repository’s local config, making it far simpler to share the same hooks across multiple projects.

A minimal example looks like this:

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

The hook.<name>.event key defines the event that triggers the hook, while hook.<name>.command specifies the command to run. You can define multiple hooks for the same event; Git executes them in the order it encounters them in configuration. The traditional script in the hooks directory still works and runs last.

To see which hooks are active, use git hook list pre-commit, specifying the event type. The manual page documents list as a subcommand that prints hooks for a specific event.

More efficient maintenance by default

On the maintenance front, Git 2.54 makes geometric the default strategy for manual maintenance. When you run git maintenance run without specifying a strategy, Git now uses the geometric approach instead of the older gc task.

The geometric strategy was introduced in Git 2.52 as an explicit option; it’s now the default for manual maintenance. The documentation describes it as a complete replacement for the gc strategy and particularly recommends it for large repositories.

Other improvements

git add -p now shows, as you move between hunks with J and K, which sections have already been accepted or skipped in the current session. The same round of improvements includes --no-auto-advance, which prevents automatic progression to the next file when you reach the last hunk.

git rebase also gains a new --trailer parameter, which adds a trailer to all commits rewritten during the rebase using interpret-trailers; a typical example is a line like Reviewed-by.

Finally, aliases are no longer limited to the old ASCII alphanumeric set plus hyphens. With the new subsection syntax, any characters are allowed except newlines and NUL bytes, so you can use non-Latin names or accented characters.