Monorepo performance can suffer due to the sheer number of files in your working directory. Git’s new builtin file system monitor makes it easy to speed up monorepo performance.
The open source Git project has just released Git 2.10.0, with features and bugfixes from over 70 contributors. Here’s our look at some of the most interesting new features:
When you run
git push, you’ve probably seen a progress meter telling you how many objects you’ve sent, how many are left, and how fast the data is moving. But what happens after all of the data has made it to the server? Are we done?
Not quite. Even though the receiver of a push does as much work as possible while the data is flowing in, there are a few CPU-intensive tasks it can’t start until the whole thing has arrived. And while that’s happening, Git is completely silent. Most pushes are small enough that this phase finishes quickly, and you never notice. But when pushing a large number of objects, this can take many seconds or even minutes, leaving you to wonder if things are still working.
Worse, because the network connection is completely silent during this phase, you run the risk of the connection being dropped by HTTP proxies or other network infrastructure. That’s an easy way to turn your wondering into frustration.
Git 2.10 adds progress reports for these post-receive operations, to keep you entertained and to make sure the network knows we’re still going.
Of course you’re not always around to watch those progress meters. For pushes without a terminal (or run with
--quiet), Git 2.10 also sends periodic “keepalive” packets to keep the network connection running.
The progress reporting and keepalives are all implemented on the server side of the connection, and are backwards-compatible with all existing versions of Git. So you don’t even need to upgrade to see them (but your hosting provider does).
A few other progress-related improvements came along for the ride, too.
git clone now gives an accurate progress meter when checking that it received all of the necessary objects. And some progress messages, like those from an auto-gc of the remote repository, are more clearly marked as coming from the remote.
GPG-signed tags and commits have been a part of Git for a long time, but the workflows and tooling around them are still not that convenient to use. Git 2.10 takes a few incremental steps in this area. Along with some behind-the-scenes robustness improvements, it adds a new configuration option,
log.showSignature, to verify signatures for every invocation of
The default output format for signature verification has also been changed to show 64-bit GPG key-ids, even when using older versions of GPG (64-bit ids are already the default on newer versions). This is in response to the Evil 32 project, which showed how easy it is to generate “fake” keys which collide in the 32-bit key-id space. That project is two years old, but got new attention recently as somebody uploaded all of the fake keys from their dataset to the public keyservers.
You’ve probably seen that Git can produce colorful output in your terminal. But did you know that those colors are configurable, or that you can use them in custom
log formats and prompts? Some people get pretty fancy.
Git 2.10 comes with a few new options: its color code now understands italic and strikethrough attributes.
In addition, the
%C(auto) placeholder has been fixed (which is handy if you are designing custom
log output), color support now works out of the box on FreeBSD, and the default colors for
HEAD decorations have been tweaked to increase visibility.
- You shouldn’t ever need to debug your HTTP connections, but if you do, Git 2.10 supports the
GIT_TRACE_CURLenvironment variable. It supersedes the old
GIT_CURL_VERBOSEvariable, and gives more details, supports redirecting to a file (to avoid tangling with the rest of Git’s output), and most importantly, will automatically scrub your authentication information from the result, making it safe to share the output with a fellow debugger. [source]
- The smart-http protocol will now grow its negotiation windows more aggressively, which should result in fewer round-trips when fetching a large repository over HTTP. [source]
clone --recursivehave learned to retry a single cloning failure for each submodule, to make ephemeral server and network failures less annoying. [source]
- Manpages in the terminal will now have
literalphrases shown in bold (these are generally shown in a fixed-space typewriter font in the HTML pages, but were not decorated at all in the terminal). [source]
- Git’s internal date-formatting code can now correctly show dates past the year 2100. Phew, fixed with only 84 years to spare. [source]
git archivecan now generate tarfiles with POSIX extensions to handle files larger than 8GB, and timestamps later than the year 2242 (8 giga-seconds since 1970). [source]
That’s just a sampling of the changes in Git 2.10, which contains over 600 commits. Check out the the full release notes for the complete list.