December 1st, 2016

What’s new in Git for Windows 2.11?

Johannes Schindelin
Senior Software Engineer

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.

Performance improvements

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

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).

Author

Johannes Schindelin
Senior Software Engineer

Git for Windows maintainer

0 comments

Discussion are closed.