Changes since Git for Windows v2.14.1 (August 10th 2017)

New Features

• Comes with Git v2.14.2.
• Comes with cURL v7.55.1.
• The XP-compatibility layer emulating pthreads (which is no longer needed) was dropped in favor of modern Windows threading APIs; This should make threaded operations slightly faster and more robust.
• On Windows, UNC paths can now be accessed via file://host/share/repo.git-style paths.
• Comes with a new custom Git command git update to help keeping Git up-to-date on your machine.
• The Git installer now offers an option to keep Git up-to-date by calling git update regularly.
• Comes with BusyBox v1.28.0pre.16353.2739df917.
• As is common elsewhere, Ctrl+Left and Ctrl+Right now move word-wise in Git Bash, too.
• Comes with patch level 2 of the MSYS2 runtime (Git for Windows flavor) based on Cygwin 2.9.0.
• Comes with Git LFS v2.3.0.
• The vs/master branch can now be built in Visual Studio 2017, too
• As requested by the same user who implemented the change, Git for Windows now comes with tig, a text-mode interface for Git.

Bug Fixes

• It is now possible to override http.sslBackend on the command-line.
• The installer now detects correctly whether symbolic links can be created by regular users.
• Git Bash now renders non-ASCII directories nicely.
• A regression that caused the fetch operation with lots of refs to be a lot slower than before was fixed.
• The git-gui.exe and gitk.exe wrappers intended to be used in Git CMD now handle command-line parameters correctly.
• The core.longPaths setting is now heeded when packing refs, and other previously forgotten Git commands.
• Pressing Ctrl+Z in Git Bash no longer kills Win32 processes (e.g. git.exe) anymore, because POSIX job control is only available with MSYS2 processes.
• Git for Windows now sets core.fsyncObjectFiles = true by default which makes it a lot more fault-tolerant, say, when power is lost.
• A bug has been fixed where Git for Windows could run into an infinite loop trying to rename a file.
• Before installing Git for Windows, we already verified that no Git Bash instance is active (which would prevent files from being overwritten). We now also verify that no git.exe processes are active, either.