New Year, new Git release

If your New Year’s resolution was to update to a new version of Git, we’ve got good news. The Git community has just released Git 2.7.0, and we’d like to share some of its highlights with you.

More flexible naming for git bisect

git bisect is an awesomely powerful tool for figuring out how a bug got into your project. Just in case you’re unfamiliar with it, we’ll take this opportunity to give you a short introduction. If you already know about git bisect, feel free to skip the following section.

Review of git bisect

Suppose you get a bug report: “The hyperdrive is running backwards!” Sure enough, in the current master branch, the hyperdrive is running backwards:

$ git checkout master
$ ./test_hyperdrive
FAILURE: destination is getting farther away

“That’s funny,” you think to yourself, “I know it worked in version 4.2.” You double-check:

$ git checkout v4.2
$ ./test_hyperdrive
SUCCESS!

The question is, how did it break? Some change between version 4.2 and master must have introduced a bug.

At this point you could open your debugger or start adding print statements to the hyperdrive module. But that’s a lot of work. Luckily, there’s an easier way to discover where the bug was introduced: git bisect.

You start by telling git bisect a good and a bad version:

$ git bisect start
$ git bisect good v4.2
$ git bisect bad master
Bisecting: 2 revisions left to test after this (roughly 1 step)
[8cc2d9b4f02ccc208bd9f6d6b01ac6ed57fbb606] Take advantage of available wormholes

As soon as you do so, git bisect chooses a revision roughly midway between the known-good and the known-bad revisions. Your job is to test this version then tell Git the result of your test:

$ ./test_hyperdrive
SUCCESS!
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[f97f670fb5303ea0097e4475ec8fcf3e2c7dde85] Hyperdrive: bypass the compressor

You continue like this, each time halving the gap between the newest known-good and the oldest known-bad revisions:

$ ./test_hyperdrive
SUCCESS!
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e0cbfe825a0285e58c59cefb9b78abff2ae0c369] Implement hyperdrive parity inverter
$ ./test_hyperdrive
FAILURE: destination is getting farther away
$ git bisect bad
e0cbfe825a0285e58c59cefb9b78abff2ae0c369 is the first bad commit
commit e0cbfe825a0285e58c59cefb9b78abff2ae0c369
Author: Some Developer <me@example.com>
Date:   Thu Dec 31 14:05:09 2015 +0100

    Implement hyperdrive parity inverter

:100644 100644 a9562e3d7cea826ed52072e9b104bc9f7e870cf9 da2bc4f6d15943dcf4872641fae08d79d7696512 A  hyperdrive/parity.c

Congratulations! You now know that commit e0cbfe8 introduced the bug. Often, viewing the changes made by that commit makes it obvious what the mistake was and how to fix it. If not, at least you’ve dramatically narrowed down the amount of code that you have to debug.

When you’re done, type git bisect reset to end the bisection session.

git bisect: not just for regressions anymore

Although git bisect is most often used to find software regressions, it should be clear that the same approach can find any change that was introduced into the software; for example,

• When did a certain feature slow down?
• When did the size of the images directory grow beyond 5 MB?
• When was a particular bug fixed?

git bisect could always locate such changes. But regardless of what kind of change you were looking for, you always had to type good to mark revisions before the change and bad to mark revisions after the change. This could be very confusing, especially if you wanted to find the commit that fixed a bug¹.

To better support such uses, git bisect now allows you to use different terms in place of good and bad. With no extra setup, you can now use the more neutral terms old and new to represent “the old state of affairs” and “the new state of affairs”:

$ git bisect start
$ git bisect old v4.2
$ git bisect new master

You can even invent your own terms. Just specify them when you start the bisection:

$ git bisect start --term-old yucky --term-new yummy
$ git bisect yucky v4.2
$ git bisect yummy master

[source]

New configuration setting for --recurse-submodules

If you use Git submodules, you have probably made the mistake of pushing changes to your main module without first pushing the corresponding changes that you made in your submodules. What you should have done, of course, is use the --recurse-submodules option; for example,

$ git push --recurse-submodules=on-demand origin

Now there is a new configuration option that you can use to save the extra typing (and the embarrassment of pushing incomplete work):

$ git config push.recurseSubmodules on-demand

If you’d rather have Git just warn you about potential problems, then use

$ git config push.recurseSubmodules check

You can override this configuration setting by typing --no-recurse-submodules on the command line. [source]

Continued worktree improvements

Do you remember the git worktree command that was introduced in Git 2.5.0? It allows you to create multiple working copies that are connected to a single local Git repository.

In Git 2.7.0, git worktree continues to get better:

• With the new git worktree list command, you can list the worktrees linked to the current repository and the branch checked out in each one. [source]
• git bisect can now run in any worktree, or even in two worktrees simultaneously. [source]
• You can now clone from a linked worktree. [source]
• Submodules support for worktrees is improving. [source]

Git LFS support for git p4

git p4 is a bridge between Git and Perforce. It can fetch commits from Perforce into Git, and push commits from Git to a Perforce server. It allows you to use Git locally, even if you ultimately have to push your changes to a Perforce server. (There are similar tools to bridge between Git and Subversion, Mercurial, Bazaar, TFS, and others.)

git p4 now has support for storing large files in Git LFS (“Git Large File Storage”). This allows you to store large files from Perforce (e.g., media files) outside of your Git repository to avoid bloating the repository on disk. (Note that this feature doesn’t yet support git p4 submit.) [source]

More uniform commands for listing references

Git has three main ways to list references: git branch, for listing branches; git tag, for listing tags; and git for-each-ref, for listing references of any kind. But these commands, despite their overlapping functionality, had differing capabilities and options.

Now, thanks to the work of Google Summer of Code student Karthik Nayak, these commands now have a more uniform interface, and have also gained some features along the way. Now all three commands support the following options:

• --points-at <object>: list any references that point at the specified object
• --merged [<commit>]: only list references that have been merged into commit (HEAD by default) :
• --no-merged [<commit>]: only list references that have not been merged into commit (HEAD by default) :
• --contains [<commit>]: only list references that contain the specified commit (HEAD by default)

They have also gained new formatting and sorting options. [source] [source]

Other changes

• git stash show now supports two configuration settings, stash.showPatch and stash.showDiff, that select how it should display stash entries by default. [source]
• git blame now works correctly with the --first-parent option, and also when --reverse and --first-parent are used together. [source] [source]
• The appearance of gitk on high-DPI monitors has been improved. [source]
• Security fixes:
  • Avoid integer overflow when computing diffs. [source]
  • Limit submodule recursive fetches to safe protocols. [source]

  We recommend that everybody upgrade to a version of Git with these fixes, namely Git 2.3.10+, 2.4.10+, 2.5.4+, 2.6.1+, or of course 2.7.0+.

The rest of the iceberg

As usual, if you would like to know more details about what is new in Git 2.7.0, please refer to the full release notes.

This Git release has more than 800 commits from 81 contributors. Here’s to a great 2015 and an even better 2016!

[1] It might seem that git bisect shouldn’t care whether the change you are looking for was from bad to good or from good to bad. But in fact, if the first two commits that you mark are not direct ancestor/descendant of each other, git bisect has to examine some common ancestors of those commits. In that case, the logic is different depending on the direction of the transaction that you are looking for.