What's coming in Git 2.55

The current release, v2.54, added an experimental "git history" command. It is, in many ways, like "git rebase", in that it allows the rewriting of commits in the history, but there are some significant differences, mostly aimed at making rebasing a bit less of a fraught operation. It can work on bare repositories, which may be of use to some people. Perhaps more widely useful is "git history reword", which makes it easy to edit the changelog of a past commit with a single command.

There is one aspect of how "git history" behaves that is worthy of note: unlike "git rebase", it will cause the rebasing of all local branches that descend from the modified commit, not just the current branch. That is likely to be what is wanted most of the time, but it has the potential to generate surprises if one is experimenting with it on a throwaway branch. I have, of course, simply understood that this could happen from my perusing of the source, and would never have actually unintentionally changed an important branch by playing around in this way. The "--update-refs=head" option can be used to restrict the rebase to the current branch only.

Anyway, "git history" is still marked as being experimental, but it is also gaining more features; new to 2.55 is "git history fixup". It can be thought of as a variant of "git history reword" that changes the body of the commit rather than the changelog. If a given commit (let's call it abcdef01) made a change to a file (call it foo.c), but neglected to update a comment, one can always repair the situation later with git rebase. But an alternative is to simply edit foo.c to make the desired change, then:

    git add foo.c
    git history fixup abcdef01

The indicated commit will be amended with the changes to foo.c, and all branches descending from it will be rebased on top of the new version. The changelog of the affected commit will not be modified unless the "--reedit-message" option is provided. If, however, merge conflicts arise during the rebasing, the command simply aborts.

Other additions include the "git format-rev" command, which reads one or more commit IDs and formats them using a provided "pretty" string. This example from the man page:

    git last-modified -- <files> | git format-rev --stdin-mode=text --format=%an

Will print the name of the developer who last modified each of the given files.

The Git "fsmonitor" is a daemon process that watches the current directory and makes a note of changes made there. Various Git subcommands, such as "git status", can query the fsmonitor daemon rather than scanning through the directory for changed files. On systems where filesystem access is slow and repositories are big, using the fsmonitor daemon can significantly speed things up. This feature has been unavailable for Linux systems — until now. As of 2.55, the fsmonitor daemon has a Linux implementation as well.

The "git push" subcommand can now push changes to a "remote group", which is just a list of independent remotes. Groups are defined in the Git 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 be set up to run in parallel, speeding execution overall.
• More Lisp dialects are understood by the diff generator.
• The "git url-parse" subcommand can be used to split out the components of a URL; this is useful because Git has a number of special additions to the URL format that other URL parsers do not understand.
• The "--max-count-oldest" option to "git rev-list" and "git log" can be used to request the N oldest commits within the specified range.

Beyond that, of course, there have been many performance optimizations, various minor tweaks, and a long list of bug fixes. As of this writing, this release has 486 non-merge commits overall, and appears to have stabilized. The 2.55 release can thus be expected soon, and the Git community will move on to the 2.56 development cycle.

Note: you can avoid this step in the future by logging into your LWN account.