Git 2.11 has been released! It's 3 months since Git 2.10 was released. This blog post will cover the most interesting changes between Git 2.10 and Git 2.11. The post is meant to be a TL;DR type of a conclusion of the interesting stuff for those who don't want to spend their time glancing through the official release notes.
Better Git-LFS performance
Lars Schneider has been working on a new
git-filter protocol. The changes are included finally in Git 2.11. Git Rev news already covered the work of Lars exhaustively during August, and you can read the full story here. The difference in execution speed for certain commands with the new protocol is tremendous as you can see from the example below (switching branches on OSX with 12,000 Git LFS files):
Default Git and Git LFS: 6m2.979s + 0m1.310s = 364s Git and Git LFS with filter protocol support: 0m2.528s + 0m2.280s = 5s
The execution time is 70 times faster in this particular use case. Windows users should expect "even more dramatic results", as launching new processes is usually slower.
Git 2.11 introduces automatic scaling to the default abbreviation length. Let's take the output of
git log --oneline for example. In Git 2.10 and a small repository the output would look something like the below:
And compare it with the output from Git 2.11 and the Git repository itself, we can see the difference.
Git 2.11 shows 9 digits whereas Git 2.10 shows only 7. The same change applies to every command that uses the abbreviation, not just
Basically, 7 digits wasn't enough to distinguish commits in Linux kernel development nor Git development itself. The new dynamic scaling of abbreviation takes into account the approximate number of objects in the repository and adjusts it accordingly.
Error handling with abbreviated commits that are not unique in git commands is also improved. Before Git 2.11 the commands would simply fail with
ambiguous argument but Git 2.11 hints the user with a list of commits with the given prefix. This will help you to choose the correct commit.
New version of Git-gui
Git 2.11 comes packed with a new version of
git-gui is a Tcl/Tk based graphical user interface that focuses on allowing users to make commits, amend existing ones, create branches, perform merges in addition to pull and push to and from remote repositories.
git-gui is a power tool for doing specific tasks, whereas
gitk is more of a general purpose graphical client.
Experimental heuristics git-diff
Git 2.9 introduced the
--compaction-heuristic option to
git diff command, which distinguished similar line changes better if they are separated by an empty line. Git 2.11 adds another switch
git diff command, which distinguishes similar line changes better. This might be the default in future versions of Git. With a small testing, the indent heuristic was at least able to distinguish simple changes with similar lines similarly as the compaction heuristic.
Both of the options above are available in Git 2.11, so test them out in case you find the output of
git diff to be ambiguous. Remember that both of the above are experimental and off by default. If you would like to configure the indent heuristic as default, you can add the following to your
[diff] indentHeuristic = on
or simply run
git config --global diff.indentHeuristic on on the command line. You can find more about the testing infrastructure for both heuristics here.
Other intriguing changes
Git 2.11 also includes the possibility to reject an incoming push with too many bytes. This allows servers and code hosting platforms to control the amount of incoming data they receive at a time.
Interesting changes overall. There are myriads of others, and you can read all about them from the official release notes. To try the new changes out, download Git 2.11 from the official site.
What was your favorite change in Git 2.11? Comment below and let us know.