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 git.github.io.
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://192.168.67.1:32767Without 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 abortedThis patch was required to work behind a faulty AP and scraped from http://stackoverflow.com/questions/15227130/#15228479 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.
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 (http://www.xkcd.com/1360/), 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 https://github.com/gitster/git/, 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 http://stevelosh.com/blog/2013/04/git-koans/#the-hobgoblin 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.
Various
Light reading
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com> and Nicola Paolucci <npaolucci@atlassian.com>, with help from Stefan Beller and James McCoy.