Skip to content

Latest commit

 

History

History
332 lines (267 loc) · 22.6 KB

2018-06-20-edition-40.markdown

File metadata and controls

332 lines (267 loc) · 22.6 KB
title layout date author categories navbar
Git Rev News Edition 40 (June 20th, 2018)
default
2018-06-20 12:06:51 +0100
chriscool
news
false

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 git.github.io.

This edition covers what happened during the month of May 2018.

Discussions

General

  • Microsoft acquires Github for $7.5 billion

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.

Support

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 no one 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

  • Who are you and what do you do?

    I graduated with a software engineering degree from École Polytechnique de Montréal. I'm currently a software architect on the OCTO team at Linaro. I spent most of my professional life working on the Linux kernel for the ARM architecture. And being a code tinkerer at heart, I am often looking at assembly output from the compiler to see what it made of my code.

  • How did you get involved in Git?

    When Linus Torvalds announced that he'd be taking a break from kernel work to dedicate some time to the creation of a new code management system of his own then I got intrigued. I expected this new system to have an impact on my kernel work flow so I wanted to test it early on. And of course I quickly got annoyed by all the shortcomings Git had in those early days, so I started making patches and became a regular contributor for a few years.

  • What would you name your most important contribution to Git?

    Delta compression, and object packing heuristics. Getting git-repack to produce smaller packs and do it faster became an obsession of mine for a while.

  • If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?

    The git pack format version 2. This is something I worked on for a while, from the format definition to the first proof-of-concept implementation. The initial pack size reduction over the current format was really interesting (around 20%) and the potential for significant runtime speed-ups was there in theory. In practice that meant reworking most of git's inner core code to benefit from all the direct object references provided by that pack format. The existing proof of concept simply implemented backward compatibility with the rest of git which made it slower than the current pack format. And because the current format is already quite efficient already, this project was facing diminishing returns and I could no longer justify the required time to work on it. But... if I could get a team for a year...

  • As a git user, what functionality would you like to see implemented?

    I really get annoyed when fetching a tracked repository and all the tags from that remote repo are merged with my own tags, or with tags from another remote repo. We have a separate namespace for remote branches but not for remote tags. That makes it very hard to know where a particular tag comes from, and "git remote rm" doesn't get rid of them either. This also pollutes the git-describe output.

    I think remote tags should have separate namespaces by default just like remote branches, with similar disambiguation rules when referring to a tag using a partial path. That's something I meant to implement myself for years now but never got around to it.

  • If you could remove something from Git without worrying about backwards compatibility, what would it be?

    Some of the early choices I made in the delta compression encoding format. But that format is simply too widely used now to consider incompatible changes just for the sake of being marginally more efficient.

  • What is your favorite Git-related tool/library, outside of Git itself?

    I'm pretty much a pure-git user and never got used to any of the associated tools. I grew my git usage while I was also a git developer with a pretty good knowledge of its internals and native capabilities. Most tools on top of git are meant to provide a different user experience that always gave me the impression they were in the way of the actual basic git command I wanted to use.

Releases

Other News

Security

Events

Various

Light reading

Git tools and sites

  • Adam Spiers has developed a set of four tools supporting higher-level git workflows:

    • git-splice - (non-interactively) splices commits into/out of current branch
    • git-transplant - (non-interactively) transplants commits from current branch into/onto another
    • git-deps - automatically detects textual dependencies between commits
    • git-explode (recently released) - automatically explodes a linear sequence of git commits into new independent topic branches

    Last month he presented demonstrations of these to the Git London User Group. His blog post "git auto-magic" provides links to the video and slides from the talk, and more information about each tool.

  • GitHub Evacuation Project: on GitHub and on GitLab

  • git-ssb is a totally decentralized git interface (decentralized version of GitHub / Bitbucket / GitLab), with familiar interface for raising issues, forking, opening pull requests, etc. It uses Secure Scuttlebut decentralized gossip protocol. Its development started on GitHub, but has been since moved to git-ssb itself (Repo ID: %n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256), and GitHub project is now in archived state. There exist online portals serving git-ssb over HTTP(S): https://gitmx.com, https://git-ssb.celehner.com, http://git.mixmix.io, https://git.scuttlebot.io

    • git-ssb-intro - Learn git-ssb: a decentralized GitHub alternative

  • BitHubLab: Search for open source repositories on github, gitlab, and bitbucket all at once

  • GitHub Pull Request Rejection Bot - effectively disable pull requests for your repo on GitHub

  • Continuous Integration for projects using a patch-based, mailing-list-centric git workflow:

  • Distributed bug tracking

    • bug: distributed bug tracking with the filesystem and hg or git
    • Bugs Everywhere is a “distributed bugtracker”, designed to complement distributed revision control systems, supporting Arch, Bazaar, Darcs, Git, Mercurial, Monotone

  • isomorphic-git (homepage) is a pure JavaScript implementation of git for Node.js and browsers

Credits

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