Development

New features in Git 2.9

By Nathan Willis
June 15, 2016

Git version 2.9 was released on June 14. While there are no major new functional changes, the update includes quite a few improvements likely to be appreciated by developers and project maintainers, including several improvements to submodule support, new safety features to prevent occasional accidental disasters, and changes to working with diffs, logs, and hooks.

For some users, the highlight of the new release will be that the git-multimail tool is now officially included (in the contrib/ directory). Git-multimail is a notification tool that can be used to send out email notifications on pushes to a Git repository. It is an extension of Git's old email-notification hook with a larger set of configuration options. Git-multimail is, among other differences, more granular in its notifications: it will, by default, send one email for every commit. In contrast, if multiple commits changed a particular file, but all of the commits were pushed together, the old hook would only send out one notification for the file.

Safety first

The experimental "multiple working tree" feature was introduced in Git 2.5, allowing users to check out multiple branches at the same time and enabling features like having a working tree stored on a removable storage device or a network share. Though still marked as experimental, the feature has seen some additional development, disabling operations (such as renames and deletions) on any branch with an active working tree that is in use elsewhere. That change could help prevent unwanted surprises, to say the least.

Along the same lines, git merge will now no longer allow merging unrelated branches unless the user explicitly passes the --allow-unrelated-histories flag. This change was made to support workflows that rely on using several branches that do not share a common revision history (for example, a docs branch that contains the project documentation outside of the source code). Preventing merges between branches with unrelated histories should help avert accidents like someone unintentionally merging the documentation branch of a project into the main branch. Interest in the feature stemmed from confusion in the kernel-development community earlier this year.

The rebase command already supported running a command after each commit, via the -x command switch. This was convenient for workflows like running the project test suite after each commit, but in previous releases, making use of the feature also required the user to add the --interactive switch. As of 2.9.0, -x implies -i automatically, so users have one fewer option to remember.

Diffs and logs

There are several helpful improvements to the diff command in the new release. First, the new --compaction-heuristic switch activates a new heuristic that improves where diff splits up hunks. The goal is to prevent accidentally splitting up an insertion in a way that causes the hunk displayed by diff's output to be confusing to the user—usually an occurrence caused by similar lines near each other in the file. The new heuristic prefers splitting hunks on blank lines, which should avoid accidentally breaking hunks in the middle of code blocks.

Git has long supported filtering diff output to improve readability; there are many highlighting and formatting filters to choose from. But, up until now, the interactive patch-staging tool could not make use of such filters. With 2.9, it can; the interactive.diffFilter configuration variable lets users specify a set of filtering scripts.

Both the diff and log commands now have rename detection enabled by default. This enables Git to better track changes that involve file renames. Nevertheless, it is probably wise to note that Git still detects renamed files heuristically: by noting file deletions and comparing new file contents to the deleted files.

Speaking of the log command, its output will now expand tabs in commit messages into four space characters, matching the four-character indentation it uses for commit messages. While that may sound like a minor feature, it can also be used to improve formatting in commit messages, such as enabling users to include ASCII tables and diagrams that will be reproduced reliably.

Submodules

There have also been several changes affecting working with Git submodules. First, the -jobs=N flag can be used on the clone and update operations for submodules, allowing those operations to be run in parallel for faster execution on multi-core machines. Support for the --jobs switch was available for the fetch command in Git 2.8; this release simply expands its availability.

In another performance-related improvement, git clone now supports the --shallow-submodules option. "Shallow" submodules mean that the submodule repositories will be cloned only to a depth of one commit. This is most useful when the user does not need a project's entire history.

Git can also now pass command-line configuration options down to submodules when cloning or fetching them. This feature allows users to pass down important options like -c credential.* variables or to override the default settings. Examples include turning off various filters, which can improve the speed of clone and fetch operations.

Other features

As always, the new release incorporates dozens of updated features and small improvements. Users would do well to skim through the entire list in the release notes. There are, of course, a few standouts. For one, users can now specify a custom path for hooks, rather than being required to store all hooks within a repository. That should make it easier for developers to use a common set of hook scripts stored in a single location; the path to the hooks needs to be specified in the new core.hooksPath configuration variable.

There is also a new configuration variable to let users set the --verbose switch to "on" by default for git commit. This causes the commit helper to display a diff of the staged changes, which can be helpful for writing meaningful commit messages late at night when memory can occasionally fail. In addition, there are quite a few internal changes, some of which will be made visible in future releases—such as work refactoring the references API in preparation for the eventual support of pluggable reference backends.

This development cycle also saw contributions from 28 new developers, which is an increase over the numbers that the project reported for Git 2.8.0.

Comments (1 posted)

Brief items

Quotes of the week

One thing I experienced many times at Mozilla was users pressuring developers with nastiness --- ranging from subtle digs to vitriolic abuse, trying to make you feel guilty and/or trigger an "I'll show you! (by fixing the bug)" response. I know it happens in most open-source projects; I've been guilty of using it myself.

I particularly dislike this tactic because it works on me. It really makes me want to fix bugs. But I also know one shouldn't reward bad behavior, so I feel bad fixing those bugs.

— Robert O'Callahan explores the dark side of bugfixing.

Everything's awful, and the fact our computers can continue to display text to us is a goddamn miracle. Never forget that.

— Paul Tagliamonte reflects on Unicode, time zones, and other facts of life. (Thanks to Paul Wise.)

Comments (none posted)

Git v2.9.0 released

Version 2.9.0 of the Git source-code management system is out. There are various improvements and small changes that maintainers of scripts using Git will want to look at, but no major changes.

Full Story (comments: 4)

F-Droid 0.100 is available

Version 0.100 of the F-Droid app for Android has been released. This is the official client app for installing free-software Android apps from the F-Droid repository (and other, third-party app repositories). The new release is noteworthy for its support of downloading apps in the background, support for automatically updating installed apps, and adding indicators of where each installed app comes from.

Comments (8 posted)

Revisiting Daala Technology Demos

Jean-Marc Valin of the Xiph project has published an update documenting recent progress on the Daala video codec. The report notes several experimental codec components that have been tried and abandoned, and it provides updated results for a variety of tests. Though still far from being finished, Daala has been making steady gains in comparison to other codecs (both free and proprietary).

Comments (none posted)

Nextcloud 9 released

Nextcloud 9 has been released; the first major update since Nextcloud was forked from the ownCloud project in early June. The release is not merely a rebrand; new functionality includes anonymous file upload and several security-hardening measures.

Comments (none posted)

Newsletters and articles

Development newsletters from the past week

Comments (none posted)

Grover: Why Rust for Low-level Linux programming?

On his blog, Andy Grover makes a case for using the Rust language for new projects instead of C or Python. "Second, there are people like me, people working in C and Python on Linux systems-level stuff — the “plumbing”, who are frustrated with low productivity. C and Python have diametrically-opposed advantages and disadvantages. C is fast to run but slow to write, and hard to write securely. Python is more productive but too slow and RAM-hungry for something running all the time, on every system. We must deal with getting C components to talk to Python components all the time, and it isn’t fun. Rust is the first language that gives a system programmer performance and productivity. These people might see Rust as a chance to increase security, to increase their own productivity, to never have to touch libtool/autoconf ever again, and to solve the C/Python dilemma with a one language solution."

Comments (117 posted)

Lortie: Gtk 4.0 is not Gtk 4

Allison Lortie writes about a new proposed GTK release scheme that may take some getting used to. "Meanwhile, Gtk 4.0 will not be the final stable API of what we would call 'Gtk 4'. Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it. These incompatible minor versions will not be fully parallel installable; they will use the same pkg-config name and the same header file directory. We will, of course, bump the soname with each new incompatible release — you will be able to run Gtk 4.0 apps alongside Gtk 4.2 and 4.4 apps, but you won’t be able to build them on the same system. This policy fits the model of how most distributions think about libraries and their 'development packages'." Only the last release in each major number series (expected every two years) would have a stable API. Read the whole thing to fully understand what is being proposed.

Comments (132 posted)

Page editor: Nathan Willis
Next page: Announcements>>