Git 2.54: move hooks into config and rewrite history without heavyweight interactive rebase

Git 2.54 removed two small but annoying pains

Git 2.54 is not trying to reinvent version control. It does, however, remove two pieces of routine friction: hooks scattered around .git/hooks, and the heavier manual dance with rebase -i when you only need to fix one commit.

If your team uses shared checks before commit or does small history edits often, this release really saves time. Not “wow, a new Git”, more like “finally, fewer rituals”.

What changed

The first piece of novelty is config-based hooks. You can now describe a hook in Git config instead of only dropping a shell script into .git/hooks. That means the same script can be attached to multiple repositories, multiple events, and even rolled out through system or global config.

The second piece is git history. It is a new experimental way to rewrite history for narrow jobs: change a commit message or split one commit into two. It is not trying to replace all of interactive rebase; it just removes some of the smaller chores.

How to move hooks into config

Start with the simplest thing. Say you have a lint script that checks code before commit and before push. Earlier, that was a separate file in .git/hooks or some wrapper in the repository. In Git 2.54, you can write it directly into config:

git config set hook.lint.command ~/.local/bin/lint.sh
git config set --append hook.lint.event pre-commit
git config set --append hook.lint.event pre-push

git config set hook.secret-scan.command ~/.local/bin/secret-scan.sh
git config set --append hook.secret-scan.event pre-commit

What matters here:

• one friendly name can have multiple events;
• several hooks can listen to the same event;
• Git runs them in the order it sees the config;
• if you need to disable a hook temporarily in one repository, just remove or unset its hook.<friendly-name>.event entries in that repo.

This is especially useful when a team keeps shared rules but does not want to copy the same scripts into every repository by hand. Less duplication, fewer “oops, this project still has the old hook” moments.

Where this works especially well

• pre-commit for a formatter or linter;
• pre-push for a lightweight secret scan;
• commit-msg for commit message templates.

When I would not rush

If a hook does complex environment preparation, pulls a lot of dependencies, or depends heavily on local project layout, the classic .git/hooks path can still be simpler. Config-based hooks are great for shared, predictable jobs, not for a tiny local 200-line shell acrobatics project.

How to rewrite history with git history

git history is not about automation anymore. It is about precise surgery. It has two basic moves:

• reword, to change a commit message;
• split, to break one commit into two.

Example:

git history reword 9c1f2ab
git history split HEAD -- src/app.ts

There are two more details worth remembering.

First, the command is marked as experimental. That is not just legal wording, it is a direct signal that the behavior may change.

Second, git history does not run hooks and does not like merge history. It can also work in a bare repository, because it does not need to touch the index or the worktree. So this is not a tool for every branch and every situation. Its strength is that it is simpler than interactive rebase when you need to quickly fix one commit or split a large one into smaller pieces.

When git history is nicer than rebase -i

• you only need to rewrite a commit message;
• you need to split one large commit into two clean ones;
• the history is linear;
• you are working locally or in a branch that does not have a wide dependent tree yet.

When interactive rebase is still the better choice

• the history has merge commits;
• you need to resolve conflicts;
• you need to rewrite many commits at once;
• you want full control over the order of the steps.

For those cases, rebase -i is still the more honest tool. It is more complex, but also easier to reason about once the history is no longer tidy.

What definitely not to do

• Do not turn on hooks in config for every repository without testing. If the hook is slow, everyone will complain about commits.
• Do not expect git history to fully replace rebase -i. It will not.
• Do not use git history on merge-heavy history, it is simply not for that.
• Do not treat the absence of hooks in git history as a bug. It is a deliberate limit, so the process does not become stateful chaos.
• Do not rewrite a shared branch without talking to the team. Git is not the villain here, but it can ruin the day nicely.

A simple rollout plan

1. Upgrade Git to 2.54+ on one test machine.
2. Move one simple hook into config.
3. Verify that it fires where it should and does not annoy developers.
4. Try git history reword on a local copy of the history.
5. If everything looks fine, add a short team note so nobody has to hunt for the new workflow in old docs.

Conclusion

Git 2.54 does not make life magical, but it removes a few unnecessary manual steps. Config-based hooks are a better fit for shared rules, and git history is useful for precise edits without the heavier rebase -i flow.

My practical takeaway is simple, move one hook into config first, try one safe history rewrite next, and only then decide whether the new workflow deserves a wider rollout.