Git Rev News: Edition 10 (December 9th, 2015)

Welcome to the 10th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on

This edition covers what happened during the month of November 2015.



James Rouzier sent a patch to add a new --exclude-from=<file> option to git clean. It looked quite straightforward, but as often Eric Sunshine found many small things that could be improved upon. James and Eric then agreed on what should be done, and it looked like a clear roadmap had been set for this new feature.

That’s when Jeff King, alias Peff, wrote the following:

Lots of commands care about excludes (e.g., “add”, “status”).

Should this perhaps be an option to the main “git” to append to the set of excludes?

You can kind-of do this already with:

git -c core.excludesfile=/path/to/whatever clean …

but of course you might be using core.excludesfile already. I wonder if that config option should take multiple values and respect all of them, rather than last-one-wins.

This started a discussion between Junio Hamano, the git maintainer, and Peff about how exclude files should be specified to commands.

It is a complex topic because there are already different ways to pass an exclude file, for example there is also .git/info/exclude. And there is the question of how the option should be passed to sub commands.

In the end it is not clear if the patch will be accepted.

In a patch series called “Miscellaneous platform-independent patches from Git for Windows” Johannes Schindelin, alias Dscho, sent a patch from Pat Thoyts that adds SOCKS proxies support to Git:

With this patch we properly support SOCKS proxies, configured e.g. like this:

git config http.proxy socks5://

Without this patch, Git mistakenly tries to use SOCKS proxies as if they were HTTP proxies, resulting in a error message like:

fatal: unable to access 'http://.../': Proxy CONNECT aborted

This patch was required to work behind a faulty AP and scraped from and guarded with an appropriate cURL version check by Johannes Schindelin.

The last paragraph made Junio Hamano wonder “What is the licensing status of the original at SO?”

James McCoy answered that according to Stackoverflow “all user contributions are licensed under Creative Commons Attribution-Share Alike”.

Unfortunately as Junio replied, the Creative Commons Attribution-Share Alike, alias BY-SA, does not mesh well with GPLv2 that Git uses. That’s why Dscho asked Pat if he could give his Signed-off-by mention, which would mean that he agrees to relicense his work under the GPLv2.

Junio, after consulting his IP lawyer friends, replied that asking Pat was indeed the best thing to do.

Ten days later Pat eventually gave his Signed-off-by which fixed the problem.

Developer Spotlight: Stefan Beller

I write Git/Gerrit code for a living at Google. I started coding when I was 10 years old with a tool called GameMaker for DOS. As I did not know how to version my games back then, deep down in my digital life (, I admit having folders called v1, v2, v3.

I think all the patches I contributed using various static code analysis tools. These were small issues such as memory leaks each, but as a whole they made Git better. Which also leads to answering the next question …

I started diving into Submodule Code lately. The first patches which just landed in origin/master don’t do a lot, except making submodules a little faster by rewriting shell in C. This is the same approach as I had in the previous question, looking for stuff under the hood and improving there, is usually not controversial, so a good thing to start out with when exploring new areas of code.

I would ask the experts for a Git protocol version 2 as that makes repositories with lots of refs go smoothly over the wire. For example every time you fetch git.git today from, more than 100kB are sent over the wire and most of it is moot. A fetch today and a fetch a week ago would only differ in 5kB in these first 100kB sent over the wire. While Git as maintained by Junio has more refs than the usual repository (currently 1626 refs), there are other projects which are even larger than Git itself in the ref space.

I think I just point at where the subtle inconsistencies are put into a spotlight.

I did use only Git itself, no third party tools otherwise until recently. Now I am into Gerrit a bit for reviewing changes before it’s too late.


Other News


Light reading

Git tools and sites


This edition of Git Rev News was curated by Christian Couder <>, Thomas Ferris Nicolaisen <> and Nicola Paolucci <>, with help from Stefan Beller and James McCoy.