What's coming in Git 2.4.0

The Git project recently turned ten years old, and a new stable release, version 2.4.0, is due shortly. While the development cycle leading up to Git 2.4 has focused largely on improving polish, there are a handful of interesting new features worth checking out, plus several changes that users need to be aware of for compatibility reasons.

A "preview" release candidate (-rc0) for Git 2.4.0 arrived on March 26; the first official release candidate (-rc1) followed on April 2. The release notes that accompany both announcements highlight a lengthy list of bugfixes (many of which have also been implemented in the current 2.3.x series) as well as a large set of improvements to the official documentation and to the terminal output returned by individual Git commands.

Some of those output fixes could have genuine impact on a user's workflow, of course. To cite one simple example, in previous releases, providing a non-existent name to the --author= parameter when making a commit would result in a rather terse error message that could leave users wondering what the source of the problem is. The new error message makes it explicit that the --author= parameter is at fault.

Output reporting success was improved, too; for example, the git apply --whitespace=fix command now actually returns a message whenever it fixes white-space problems. The release notes point out, though, that some of the changes to output formatting (in particular with git log and git branch) could result in backward incompatibilities. Users that parse the output from these commands in software will need to update their code.

For most users, though, it is new functionality that will attract the most attention. Topping the list for Git 2.4.0 might be the addition of the --atomic option when doing a push. Not to be confused with "the nuclear option," this switch is actually used when the push in question is meant to update more than one reference (say, HEAD and an important remote reference). Adding --atomic ensures that if any of those updates fails, all of the others will fail, too, thus keeping things from getting out of sync.

A push-to-deploy feature was added in Git 2.3, allowing users to use the push command to deploy changes directly onto a running system. That feature has seen some improvement for 2.4, with the user being able to customize the behavior of the server's repository using the push-to-checkout hook. The example included in the patch's documentation involves a hook that lets the server retain any locally-changed files that do not interfere with the changes being pushed. It is not clear at the moment how many people use Git to deploy software on live servers, but additional flexibility is certainly welcome for those who do.

Among the other tools, there are several new features to point out. An --invert-grep option has been added for the log command. As one would surmise from its name, this allows users to search their logs for commits that do not match a particular pattern. There is also a new GIT_TEST_CHAIN_LINT mechanism for use in test scripts. It allows users to check the syntax of their test scripts, hopefully avoiding those situations where a test is silently skipped because of a syntax error, but the resulting silence is interpreted as a passed test.

The status command already included a -v switch to enable verbose output, but that switch only displays a verbose diff between the index file and the current HEAD. Starting with Git 2.4.0, adding a second -v switch will also show a verbose diff of the uncommitted changes. The archive command can now set the text attribute (which specifies the end-of-line style) on the archive files it generates.

There are also a few new configuration options that may prove interesting. The versionsort.prerelease variable can be used to indicate that version numbers like "1.0-pre1" should come before "1.0." The push.followTags configuration variable makes the --follow-tags option the default for pushes.

The 2.4.0 release does not incorporate a large number of new features, but the significant set of small improvements is a testament to just how active the community remains. Git, even at ten years old, is still adapting to new use cases and the needs of new users.

That process does not appear to be slowing down, either. GitHub just announced a new feature that enables support for large files: audio and video, graphics, and data sets. Dubbed Large File Storage, the open-source extension replaces large files in the Git repository with pointers to external storage. No word yet on whether such a feature will find its way upstream, but considering the pace at which Git development moves now, it would not be a surprise, if enough users find it helpful.