What’s new in Git for Windows 2.11?
Git for Windows v2.11.0 is out! Download it here (homepage is here).
The new version corresponds to Git v2.11.0 (release notes are here, and our friends over at GitHub blogged about it, too). Apart from the improvements inherited from the “upstream Git” project, Git for Windows also updated some libraries to address security concerns, and dropped support for Windows XP.
The new Git version features speed improvements all over the place. It is my pleasure to say that some of these improvements originate in the Git for Windows project itself, such as the acceleration of
git rebase‘s startup phase by making the patch ID generation smarter.
A few more speedups went into Git for Windows specifically
- the hash generation now leverages OpenSSL’s Intel CPU support, which speeds it up noticeably.
- When working in large worktrees,
git addis now a lot faster.
- The “fscache” feature that already speeds up most disk accesses now plays better with sparse checkouts.
- The internal cache to handle file names in a case-insensitive manner is now much more efficient.
Even if Git for Windows does not ship with Git LFS (due to size concerns), the new Git for Windows has support for substantially faster clones when using many binary files managed by Git LFS.
Experimental, faster difftool
One of the factors contributing to Git for Windows “feeling” slower than, say, Git on Linux, is the fact that some Git functionality is actually not implemented in native code, but as shell or Perl script. As neither a shell nor a Perl are provided by default in a regular Windows setup, Git for Windows ships with a “pseudo POSIX” environment called MSYS2 (which is in turn based on Cygwin). The need for this POSIX emulation layer slows things down considerably.
That is the reason why the Git for Windows converts scripted parts into native code, as was done with the interactive rebase in Git for Windows v2.10.
In Git for Windows v2.11, there is now a
difftool that is a “builtin”, i.e. native code. As the new builtin difftool needs more wide-spread testing, it is an opt-in feature; by default,
git difftool will still call the original script.
Visual Studio support
By far the most effort in the v2.11 cycle has gone into building Git for Windows’
master branch with Visual Studio. In fact, there are two ways to build via Visual C: using the command-line, and in Visual Studio. Both options work using Visual Studio’s Community edition, by the way.
I would like to indulge in enumerating just a couple of the goodies now available to us:
- Code navigation! The
Ctrl+,keyboard shortcut to navigate to declarations, definitions, and files, is easily my most favorite tool here.
- Refactoring tools! Visual Studio comes with a couple of functions that make refactoring much more painless.
- Debugging! Visual Studio’s integrated debugger offers nifty features such as inspecting code, single-stepping, and hot-patching changed code. It is hard not to love having those options.
- Profiling tools! These tools already helped identify a couple of bottlenecks.
It was far from easy to get to that point, and I cannot thank enough all the people involved with this effort, in particular Jeff Hostetler and Philip Oakley, for their tenacity and code contributions. Git for Windows already had a script to generate Visual Studio project definitions since 2009, with a recent effort to bring the script up-to-date and to fix Git’s source code to build correctly.
The official Git for Windows will still be built with GNU C (“GCC”), simply because you should never change a winning team. Oh, and the Git project itself uses GCC, too, hence we avoid battling unnecessary fights by sticking to GNU C for the official releases.
But it is really nice to have the option to simply clone, check out the
vs/master branch, immediately start playing with the source code, and then run the test suite from a regular Git Bash (no Git for Windows SDK required).