What's coming in Git 2.55 [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
What's coming in Git 2.55
We're bad at marketing
We can admit it, marketing is not our strong suit. Our strength is<br>writing the kind of articles that developers, administrators, and<br>free-software supporters depend on to know what is going on in the<br>Linux world. Please subscribe today to help us keep doing that, and so<br>we don’t have to get good at marketing.
By Jonathan Corbet<br>June 26, 2026
The Git v2.55.0-rc2<br>testing release appeared on June 23, suggesting that the final Git<br>2.55 release can be expected in the near future. While this Git update<br>lacks radical new features, it does include a number of improvements that<br>regular Git users will appreciate, including commands to easily edit the<br>commit history, more formatting options, fsmonitor support for Linux, and<br>more.
The current release, v2.54, added an experimental "git<br>history" command. It is, in many ways, like "git rebase",<br>in that it allows the rewriting of commits in the history, but there are<br>some significant differences, mostly aimed at making rebasing a bit less of<br>a fraught operation. It can work on bare repositories, which may be of use<br>to some people. Perhaps more widely useful is "git history reword",<br>which makes it easy to edit the changelog of a past commit with a single<br>command.
There is one aspect of how "git history" behaves that is worthy of<br>note: unlike "git rebase", it will cause the rebasing of all<br>local branches that descend from the modified commit, not just the current<br>branch. That is likely to be what is wanted most of the time, but it has<br>the potential to generate surprises if one is experimenting with it on a<br>throwaway branch. I have, of course, simply understood that this could<br>happen from my perusing of the source, and would never have actually<br>unintentionally changed an important branch by playing around in this way.<br>The "--update-refs=head" option can be used to restrict the rebase<br>to the current branch only.
Anyway, "git history" is still marked as being experimental, but it<br>is also gaining more features; new to 2.55 is "git history fixup".<br>It can be thought of as a variant of "git history reword" that<br>changes the body of the commit rather than the changelog. If a given<br>commit (let's call it abcdef01) made a change to a file (call it<br>foo.c), but neglected to update a comment, one can always repair<br>the situation later with git rebase. But an alternative is to<br>simply edit foo.c to make the desired change, then:
git add foo.c<br>git history fixup abcdef01
The indicated commit will be amended with the changes to foo.c,<br>and all branches descending from it will be rebased on top of the new<br>version. The changelog of the affected commit will not be modified unless<br>the "--reedit-message" option is provided. If, however, merge<br>conflicts arise during the rebasing, the command simply aborts.
Other additions include the "git<br>format-rev" command, which reads one or more commit IDs and<br>formats them using a provided "pretty" string. This example from the man<br>page:
git last-modified -- | git format-rev --stdin-mode=text --format=%an
Will print the name of the developer who last modified each of the given<br>files.
The Git "fsmonitor"<br>is a daemon process that watches the current directory and makes a note of<br>changes made there. Various Git subcommands, such as "git status",<br>can query the fsmonitor daemon rather than scanning through the directory for<br>changed files. On systems where filesystem access is slow and repositories<br>are big, using the fsmonitor daemon can significantly speed things up. This<br>feature has been unavailable for Linux systems — until now. As of 2.55,<br>the fsmonitor daemon has a Linux implementation as well.
The "git push" subcommand can now push changes to a "remote group",<br>which is just a list of independent remotes. Groups are defined in the Git<br>configuration file; a command like:
git config remotes.new-remote "remote1 remote2"
Would create a group named new-remote. A subsequent:
git push new-remote
Will push to both remote1 and remote2.
Other changes of note in this release include:
Git hooks that are set up via the configuration system can now<br>be set up to run in parallel, speeding execution overall.<br>More Lisp dialects are understood by the diff generator.<br>The "git url-parse" subcommand can be used to split out the<br>components of a URL; this is useful because Git has a number of<br>special additions to the URL format that other URL parsers do not<br>understand.<br>The "--max-count-oldest" option to "git rev-list" and<br>"git log" can be used to request the N oldest commits<br>within the specified range.
Beyond that, of course, there have been many performance optimizations,<br>various minor tweaks, and a long list of bug fixes. As of this writing,<br>this release has...