Git Rev News: Edition 40 (June 20th, 2018)

Welcome to the 40th 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 May 2018.



On Monday, June 4th, Microsoft announced an agreement to acquire GitHub for $7.5 billion in an all-stock deal. The acquisition is expected to close later this year. After Business Insider reported on Friday that Microsoft was in talks to acquire Github, Microsoft CEO Satya Nadella made it official in a blog post. After raising $100 million in 2012 in series A then $250 million in 2015 for its series B from Sequoia Capital and others, Github was last valued at $1.8 billion. The deal should be finalised before the end of this year. This is Microsoft’s second big acquisition under Satya Nadella, two years after the $26.2 billion acquisition of LinkedIn.

In his blog post, Satya Nadella stated that “Microsoft is all-in on open source”, reassured that “GitHub will remain an open platform, which any developer can plug into and extend”, adding that his company is “the most active organization on GitHub, with more than 2 million ‘commits’, or updates, made to projects”. He also detailed “three opportunities” for both companies:

  1. “Empower developers at every stage of the development lifecycle – from ideation to collaboration to deployment to the cloud”.
  2. Use Microsoft’s “direct sales and partner channels” and its “global cloud infrastructure” to “accelerate enterprise developers’ use of GitHub”.
  3. Bring “Microsoft’s developer tools and services to new audiences”.

As for Github, its CEO and co-founder Chris Wanstrath, aka defunkt, also wrote a blog post to confirm the news. He explained that “collaborating on projects from Git LFS to Electron” showed him that Microsoft and Github shared a common vision − “it’s all about the developer”. Like Satya Nadella did in his post, he also emphasized that “GitHub needs to remain an open platform for all developers”. He had already announced in August 2017 that he intended to step down as CEO, and he confirmed that he would be replaced by Nat Friedman.

Nat Friedman first founded Ximian in 1999 with Miguel de Icaza, co-creator of the GNOME project. Both met at Microsoft in 1997 when Friedman was an intern and de Icaza interviewed for a job. Ximian goal was to develop free and proprietary software that relied on GNOME. After Novell acquired Ximian in 2003, Ximian developed Mono, which aimed at bringing .NET tools to other platforms, especially Linux. As a Chief Technology and Strategy Officer for Open Source at Ximian until 2010, Nat Friedman reportedly migrated 6,000 employees from Windows to SUSE and from Microsoft Office to OpenOffice. In 2011, de Icaza and him reunited to found Xamarin, a company focused on developing Mono. Xamarin was finally acquired by Microsoft in 2016. After Xamarin’s acquisition, Friedman joined Microsoft as an employee, where he was a vice-president of Developer Services.

Nat Friedman recently gave a Reddit AMA to answer questions about the future of Github. Among other comments, he stated that:

Among the many reactions to the acquisition, both positive and negative, some developers began migrating their repos from Github to Gitlab. Gitlab declared seeing a dramatic increase in imports and customers, while Nat Friedman noted that “the set of users who have migrated […] is extremely small, and this is more than made up for by the surge of new signups […]”. On an interview with Coder Radio, Gitlab CEO Sid Sijbrandij explained that upon hearing the rumors of Github’s acquisition, they had prepared themselves for an increase in imports. As for their strategy going ahead, he said that their priority in the short term is to focus on CI and CD with “Auto DevOps”.

He also declared that Gitlab would continue to try and please projects that want an open source, self-hosted solution, like GNOME or Debian. At the same time, he underlined that “Microsoft has shown it’s a new company, they’re not pulling the tricks of the past”. According to him, the criterion for choosing Gitlab over Github is not whether companies care about open source, but rather if they want to trust somebody else’s company Software as a Service. “If you want to self host, Gitlab is the logical choice, and we want to stimulate that as much as we can”, he said to sum up the reasoning behind Gitlab’s strategy. He added that 6% of the users of the open source edition converted to the paid edition.


On May 19th Ondrej Mosnáček described an issue he had using git rebase -i --exec ....

He tried to pass something like cd <dir> && git <cmd> to the --exec option and found that it didn’t behave as it should.

Ondrej listed commands using cd src && git status to reproduce the issue which is that “git status reports as if all files in the repository are deleted”.

As noone had replied, Ondrej asked on May 27th if anyone had time to look at this.

Philip Oakley replied to Ondrej asking for more information about the directories he had created and the directory he was in when he launched the rebase command.

Ondrej said that he had to be in the top level directory of the repository for the rebase to work, and also that the commands he gave can reproduce the issue even in a current directory without any special name.

Another Phillip (with two ‘l’ instead of one), Phillip Wood, chimed in saying that he could reproduce the issue with the commands that Ondrej had given, though he could also reproduce it outside a rebase using only git status when the GIT_DIR environment variable is set to the .git directory of the repo. So Phillip thought that the problem came from git status not behaving properly when GIT_DIR is set.

Philip Oakley replied that he could also reproduce the issue. Though after experimenting he suggested git status could behave differently when attached or not to a terminal.

Junio Hamano, the Git maintainer, then chimed in to agree with Phillip Wood’s previous suggestion pointing to the GIT_DIR environment variable:

When GIT_DIR environment variable appears without GIT_WORKING_TREE, git assumes that you are starting it at the root level of the working tree. In your example, if there is README at the top-level but dir/README is not there, status would report that you removed it.

Junio also suggested a work-around:

You can unset GIT_DIR in your --exec script if you know that Git would find the right repository when run from your script.

Developer Spotlight: Nicolas Pitre


Other News




Light reading

Git tools and sites


This edition of Git Rev News was curated by Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Gabriel Alcaras <> with help from Adam Spiers, Bryan Turner, Alyss Noland and Nicolas Pitre.