Git 2.54 experiments with changing commit history

The distributed version control system Git 2.54 has been released. An experimental git history command and a changed approach to hooks are among the most important innovations in the release, which involved the contributions of 137 people.

Changing commit history with git history

As GitHub explains in a blog post, Git has already offered ways to change a project's history. For example, with git rebase -i, commits can be reordered, edited, or discarded. However, this also changes the working tree and index, which can lead to far-reaching actions.

For simple cases, the experimental command git history is now available, which is based on the functionality of git replay under the hood. git history supports the two operations reword and split. With git history reword <commit>, developers can open a commit message in the editor and adjust it, for example, to correct a typo. This also updates branches that stem from this commit. However, unlike git rebase, the working tree and index are not changed here. The second possible action, git history split <commit>, allows splitting a commit into two different commits.

Conscious limitations of the history command include that it cannot handle histories containing merge commits, nor does it perform operations that would trigger merge conflicts.

Read also

Git 2.53 makes large repositories more manageable

---

Advertisement or tip?: GitHub Copilot added product tips to pull requests

---

Textprojekte gemeinsam stemmen mit Git: So gehen Dokumentationen und mehr

More Flexible Hook Definition

Another significant innovation concerns the handling of Git hooks. Previously, these could only be defined as executable scripts located in a specific directory – by default, in the hooks subdirectory of the .git directory. This presented several difficulties, as GitHub explains: For example, if developers wanted to run a linter on all repositories before each commit, they had to copy the corresponding script into each repository, which led to extra work and potential errors.

Git 2.54 aims to solve these problems, as hooks can now be defined in configuration files. Instead of placing a script in .git/hooks/pre-commit, the following alternative is now possible:

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

This way, hooks can be defined centrally and applied to all repos. Such a configuration can be user-based in ~/.gitconfig, system-wide in /etc/gitconfig, or in a local configuration file of a repository. Developers can also define multiple hooks for a specific event or optionally disable hooks in a repository.

Further information on these and other innovations in Git 2.54 can be found in the Release Notes.

(mai)