Support for Git Wire Protocol Version 2 has been added to the latest version of the Git client. Git Wire Protocol controls how clones, fetches and pushes are communicated between clients and servers.

The Git developers say the update to the protocol removes one of the most inefficient parts of the Git protocol and fixes an extensibility bottleneck, unblocking the path to more wire protocol improvements in the future.

The Git client has received a range of other improvements, including a number of minor changes to the UI, and a variety of changes designed to improve performance. Of these, one of the more interesting is a change to the way git fetch deals with repositories with large numbers of up-to-date refs . Loose objects are now enumerated beforehand to reduce the number of wasted cycles. 

The build procedure has also been changed to optionally use symbolic links instead of hard links and copies when installing "git-foo" for built-in commands whose binaries are all identical. There are many other changes listed in the release notes.

The new protocol enables server-side filtering of references, and makes it easier to add new features. It also simplifies client handling of the http transport.

Writing about the new protocol on the Google Open Source blog, Brandon Williams of the Git-core team said:

"The main motivation for the new protocol was to enable server side filtering of references (branches and tags)."

Before the introduction of protocol v2, servers responded to all fetch commands with an initial reference advertisement, listing all references in the repository. This happened even when only a single branch was being updated. This could mean a server sending tens of megabytes of data that is all ignored, says Williams, pointing out that the Chromium repository has over 500k branches and tags as an example of the size of the potential waste. This behavior would would be the most significant cause of waste of both time and bandwidth during a fetch, especially when you are updating a branch that's only a few commits behind the remote, or even when you are only checking if you are up-to-date, resulting in a no-op fetch.

Williams said Google has seen a performance improvement of three times for no-op fetches of a single branch on repositories containing 500k references.

Another area where Git 2.18 has been improved is through work on the commit graph. There's a new (optional) serialized commit graph that could be useful if you're working with a large repository with tens of thousands of commits. In these circumstances, Git can be slow to return output.

The new serialized commit graph option comes from work Microsoft did on Visual Studio Team Services, with the concept moved to Git. The feature means Git stores the structure of the commit graph to make it faster to carry out a walk of the graph. This improves the performance when carrying out actions such as

Another new feature in Git 2.18 aimed to improve listing and filtering the commit history, according to Derrick Stolee, a former member of the VSTS Git Server team who now contributes to Git and GVFS. Stolee showed figures for experimental use of the new feature when used on the Linux kernel repository, with performance improvements of between 76 percent and 99 percent:

Stolee says the commit graph is still experimental because some features of Git don't work well when used with it.

More Information

Release Notes for Git 2.18

Stolee post on Git Commit Graph

Git Wire Protocol

Related Articles

GitHub For Unity Now Available

Git 2.17 Clarifies Moved Code

Git 2.5 Released

Visual Studio To Get Git

Git Support for Google Code Project Hosting

 Windows Source Now In A GIT Repository

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info