{"id":95374,"date":"2026-04-20T09:43:57","date_gmt":"2026-04-20T16:43:57","guid":{"rendered":"https:\/\/github.blog\/?p=95374"},"modified":"2026-04-27T15:03:23","modified_gmt":"2026-04-27T22:03:23","slug":"highlights-from-git-2-54","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/git\/highlights-from-git-2-54\/","title":{"rendered":"Highlights from Git 2.54"},"content":{"rendered":"\n

The open-source Git project just released Git 2.54<\/a> with features and bug fixes from over 137 contributors, 66 of them new. We last caught up with you on the latest in Git back when 2.52 was released<\/a>.<\/p>\n\n\n\n

To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time.<\/p>\n\n\n\n

<\/p>

💡 Since the last Git release we wrote about was Git 2.52, this blog post covers the highlights from both the 2.53 and 2.54 releases.<\/p><\/blockquote>\n\n\n\n

Rewrite history with git history<\/code><\/h2>\n\n\n\n

The Git project has a long history of providing tools to rewrite your repository’s history. git rebase –i<\/code><\/a> is the most well-known, and it’s remarkably flexible: you can reorder, squash, edit, and drop commits. But that flexibility comes with complexity: an interactive rebase operates on a range of commits, updates your working tree<\/a> and index<\/a> as it goes, and can leave you in a conflicted state that you need to resolve before proceeding.<\/p>\n\n\n\n

For simpler cases, all of that machinery can feel like overkill. If all you want to do is fix a typo in a commit message three commits back, or split one commit into two, an interactive rebase works, but requires you to set up a to-do list, mark the right commit for editing, and then drive the rebase to completion.<\/p>\n\n\n\n

Git 2.54 introduces a new experimental command that is designed for exactly these simpler cases: git history<\/a><\/code>. The history<\/code> command currently supports two operations: reword<\/code> and split<\/code>.<\/p>\n\n\n\n

git history reword <commit> <\/code> opens your editor with the specified commit’s message and rewrites it in place, updating any branches that descend from that commit. Unlike git rebase<\/code>, it doesn’t touch your working tree or index, and it can even operate in a bare repository<\/a>.<\/p>\n\n\n\n

git history split <commit><\/code> lets you interactively split a commit into two by selecting which hunks should be carved out into a new parent commit. The interface will look familiar if you’ve ever used add<\/code> in interactive mode via git add –p<\/code>:<\/p>\n\n\n

\n
$ git history split HEAD\ndiff --git a\/bar b\/bar\nnew file mode 100644\nindex 0000000..50810a5\n--- \/dev\/null\n+++ b\/bar\n@@ -0,0 +1 @@\n+bar\n(1\/1) Stage addition [y,n,q,a,d,p,?]? y <\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
After selecting hunks, Git creates a new commit with those changes as the parent of the original commit (which retains whatever hunks you didn’t select) and rewrites any descendent branches to point at the updated history.<\/p>\n\n\n\n
There are a couple of intentional limitations worth noting. 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. By design, git history<\/code> is meant for targeted, non-interactive rewrites, not the kind of open-ended history rewriting typically relegated to git rebase –i<\/code>.<\/p>\n\n\n\n
The history command is built on top of git replay<\/code>‘s core machinery, which was itself extracted into a library as part of this work. That foundation means that git history<\/code> benefits from replay<\/code>‘s ability to operate without touching the working tree, making it a natural fit for scripting and automation in addition to interactive use.<\/p>\n\n\n\n
This command is still marked as experimental, so its interface may evolve. Give it a try with git history reword<\/code> and git history split<\/code>, available in Git 2.54.<\/p>\n\n\n\n
[source<\/a>, source<\/a>, source<\/a>, source<\/a>, source<\/a>]<\/p>\n\n\n\n
Config-based hooks<\/h2>\n\n\n\n
If you’ve ever wanted to share a Git hook<\/a> across multiple repositories, you’ve probably had to reach for a third-party hook manager, or manually symlink scripts into each repository’s $GIT_DIR\/hooks<\/code> directory. That’s because, historically, Git hooks could only be defined as executable scripts living in one place: the hooks<\/code> subdirectory of your .git<\/code> directory (or whatever core.hooksPath<\/code><\/a> points to).<\/p>\n\n\n\n
That meant that if you wanted to run a linter before every commit across all of your repositories, you had to copy the script into each repository, which can be tedious and error-prone. Alternatively, you could set core.hooksPath<\/code> to point to a shared directory, but that causes all of your repositories to share the exact same set of hooks, with no way to mix and match.<\/p>\n\n\n\n
Git 2.54 introduces a new way to define hooks: in your configuration files. Instead of placing a script at .git\/hooks\/pre-commit<\/code>, you can now write:<\/p>\n\n\n
\n
[hook \"linter\"]\n   event = pre-commit\n   command = ~\/bin\/linter --cpp20 <\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
The hook.<name>.command<\/code> key specifies the command to run, and hook.<name>.event<\/code> specifies which hook event should trigger it. Since this is just configuration, it can live in your per-user ~\/.gitconfig<\/code>, a system-wide \/etc\/gitconfig<\/code>, or in a repository’s local config. That makes it straightforward to define a set of hooks centrally and have them apply everywhere.<\/p>\n\n\n\n
Even better, you can now run multiple<\/em> hooks for the same event. If you want both a linter and a secrets scanner to run before every commit, you can configure them independently:<\/p>\n\n\n
\n
[hook \"linter\"]\n   event = pre-commit\n   command = ~\/bin\/linter --cpp20\n\n[hook \"no-leaks\"]\n   event = pre-commit\n   command = ~\/bin\/leak-detector<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
Git will run them in the order it encounters their configuration. The traditional hook script in $GIT_DIR\/hooks<\/code> still works, and runs last, so existing hooks are unaffected. You can see which hooks are configured (and where they come from) with git hook list<\/code>:<\/p>\n\n\n
\n
$ git hook list pre-commit\nglobal    linter  ~\/bin\/linter --cpp20\nlocal    no-leaks    ~\/bin\/leak-detector <\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
Individual hooks can be disabled without removing their configuration by setting hook.<name>.enabled = false<\/code>, which is particularly handy when a hook is defined in a system-level config but you need to opt a specific repository out.<\/p>\n\n\n\n
Along the way, Git’s internal handling of hooks has been modernized. Many built-in hooks that were previously invoked through ad-hoc code paths (like pre-push<\/code>, post-rewrite<\/code>, and the various receive-pack<\/code> hooks) have been migrated to use the new hook API, meaning they all benefit from the new configuration-based hook machinery.<\/p>\n\n\n\n
[source<\/a>, source<\/a>, source<\/a>]<\/p>\n\n\n\n
Geometric repacking during maintenance by default<\/h2>\n\n\n\n
Returning readers of this series may recall<\/a> our coverage of the new geometric<\/code> strategy within git maintenance<\/code>, which was introduced in Git 2.52. That strategy works by inspecting the contents of your repository to determine if some number of packfiles<\/a> can be combined to form a geometric progression<\/a> by object count. If they can, Git performs a geometric repack, condensing the contents of your repository without needing to perform a full garbage collection.<\/p>\n\n\n\n
In 2.52, the geometric<\/code> strategy was available as an opt-in choice via the maintenance.strategy<\/code> configuration. In 2.54, it becomes the default strategy for manual maintenance. That means when you run git maintenance run<\/code> without specifying a strategy, Git will now use the geometric approach instead of the traditional gc<\/code> task.<\/p>\n\n\n\n
In practice, this means that your repositories will be maintained more efficiently out of the box. The geometric strategy avoids the expensive all-into-one repacks that gc<\/code> performs, instead combining packs incrementally when possible and falling back to a full gc<\/code> only when it would consolidate the entire repository into a single pack. Along the way, it keeps your commit-graph<\/a>, reflogs<\/a>, and other auxiliary data structures up to date.<\/p>\n\n\n\n
If you were already using maintenance.strategy = geometric<\/code> in your configuration, nothing changes. If you hadn’t set a strategy (or were relying on the old gc<\/code> default), you’ll start seeing the benefits of geometric repacking automatically. The gc<\/code> strategy is still available if you prefer it and can be selected with maintenance.strategy = gc<\/code>.<\/p>\n\n\n\n
[source<\/a>]<\/p>\n\n\n\n
The tip of the iceberg…<\/h2>\n\n\n\n
Now that we’ve covered some of the larger changes in more detail, let’s take a closer look at a selection of some other new features and updates in this release.<\/p>\n\n\n\n