Can projects and GitHub Actions be used by your non-developer teams? They absolutely can. Check out how our Security Team uses GitHub to run the department effortlessly.
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 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.
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
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 <firstname.lastname@example.org> 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
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
imagesdirectory 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 bug1.
To better support such uses,
git bisect now allows you to use different terms in place of
bad. With no extra setup, you can now use the more neutral terms
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
New configuration setting for
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]
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 listcommand, you can list the worktrees linked to the current repository and the branch checked out in each one. [source]
git bisectcan 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 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]
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
HEADby default) :
--no-merged [<commit>]: only list references that have not been merged into
HEADby default) :
--contains [<commit>]: only list references that contain the specified
git stash shownow supports two configuration settings,
stash.showDiff, that select how it should display stash entries by default. [source]
git blamenow works correctly with the
--first-parentoption, and also when
--first-parentare used together. [source] [source]
- The appearance of
gitkon high-DPI monitors has been improved. [source]
- 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+.
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!
 It might seem that
git bisect shouldn’t care whether the change you are looking for was from
good or from
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.