Git Rev News: Edition 15 (May 11th, 2016)

Welcome to the 15th 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 April 2016, especially at the Git Contributor Summit on April 4 2016 and at the Git Merge conference on April 5 2016.



Read part 1 in Git Rev News Edition 14

At the Git Contributor Summit on April 4th, just after the lunch break, the state of the participation of the Git project in the Google Summer of Code (GSoC) and Outreachy were briefly mentioned. Jeff King, alias Peff, then talked about the state of the Git project as a member of Software Freedom Conservancy.

Git is one of Conservancy’s Member Projects. Conservancy manages the legal and administrative aspects of the Git project, and also manages Git’s money, which amounts to around $20000. This money comes mostly from donations made on, GSoC mentor stipends, and book royalties. The money has been used in the past to pay for some developers to travel to conferences like Git Merge, and may be used in the future to pay Outreachy student stipends.

The governance of the Git project as part of Conservancy is in the hands of Junio Hamano, Shawn Pearce, and Jeff King. The main activity of the governance consists in handling trademark issues related to the “Git” trademark that the project owns.

There are a number of projects who call themselves “Git XXX” and the trademark policy on is used to decide if those trademarks are approved or not.

Another activity is related to defending the license, which is the GPLv2. For example, there have previously been vendors distributing Git with some changes, but without providing the source code for the Git version they were distributing. So far it has been possible to resolve these cases, but it is not completely clear if all vendors are currently fullfilling all of their obligations. If any developers who have contributed to Git want to take a closer look at what the vendors are doing, Conservancy is able to help them.

After that SubmitGit was discussed as well as ways to make it easier for people who are not yet Git developers to contribute. TravisCI, which can be used to automatically test pull requests that are submitted on GitHub, was also discussed at the same time.

It appeared that it would be good to also be able to test pull requests on Windows machines, but TravisCI doesn’t support Windows yet. To help on this GitLab CEO Sytse “Sid” Sijbrandij offered to let the project use GitLab CI, which supports Linux, OSX, and Windows.

Various subjects were then discussed a bit, like case insensitive refnames and filenames, submodules, and Git on Celph, which is a file system for computer clusters.

A mix of long time and quite new Git contributors, along with people from Git related projects and companies, attended. The atmosphere was relaxed and informal. Overall it was a very pleasant event.

At the Git Merge conference on April 5th 2016 at New World Stages in New York City, USA, Spencer Krum, who works for IBM in Portland and appears to be a big fan of Software Freedom Conservancy, gave an interesting and fast-paced presentation about some shell and Git command line tricks.

Some of the tricks he showed are available in his ‘bash-tricks’ GitHub repository.

The presentation started with simple shell aliases like alias sl='ls' to cope with typos and alias g='git' to reduce typing, then a bit more complex ones to avoid typing common arguments like alias gpom='git push origin master' and alias pydoc='python -m pydoc', until validation aliases like:

alias yamlcheck='python -c "import sys, yaml as y; y.safe_load(open(sys.argv[1]))"'

Spencer then spoke about customized prompts for git, filesystems and tools, and about git config aliases. For example, this alias that makes grepping through your submodules easy:

	sgrep = "!f() { git submodule foreach \"git grep '$1'; true \"
			| grep -B 1 \"$1\"; }; f"

After that came functions. Some were general like:

# Get to the top of a git tree
cdp () {
  while ! [ -d .git ]; do
  cd ..

Others were related to Gerrit or GitHub:

# Check out a Pull request from github
function pr() {
  if [ -z $id ]; then
      echo "Need Pull request number as argument"
      return 1
  git fetch origin pull/${id}/head:pr_${id}
  git checkout pr_${id}

In the end Spencer showed how to combine multiple small features to get something interesting. Take the following 3 tricks:

These 3 small tricks can be used in the following big one:

# Have vim inspect command history
vim () {
    last_command=$(history | tail -n 2 | head -n 1)
    if [[ $last_command =~ 'git grep' ]] && [[ "$*" =~ :[0-9]+:$ ]]; then
        line_number=$(echo $* | awk -F: '{print $(NF-1)}')
        /usr/bin/vim +${line_number} ${*%:${line_number}:}
        /usr/bin/vim "$@"

That makes vim open file “foo” at line “X” if one uses vim foo:X just after having run git grep.

This year only one student, Pranit Bauva, will participate in the Google Summer of Code 2016 under the Git project. He will work on incrementaly rewriting in C the parts of “git bisect” that are still in shell. He will be mentored by Lars Schneider and Christian Couder.

Developer Spotlight: David Turner

I am a free software developer (and occasional board game designer). I currently work on developer tools at Twitter. My focus is on making Git faster. I was at Git Merge and the Git Core Contributors Summit to meet other Git developers. I really enjoyed meeting you and the other contributors.

My most important contribution was probably ensuring that cache-trees are written on checkout and commit (from 2014). I’ve done a bunch of work since then on refs, the index-helper, and fixed a few really weird bugs (http range requests might be the weirdest). But most of the performance work I have done is still in-progress. The cache-tree fix has been in git since I think 2.2, and it affects daily performance for anyone using a medium to large repo.

I’m working on a few different things:

- Alternate ref backends (storing refs in a database)
- Reviewing protocol v2 patches (and, perhaps, adding new protocol
  capabilities allowing single-branch fetches to be more
- The index-helper and watchman support for faster status on large

I would rewrite all index access code to only look a the relevant portions of the index. Right now, many Git commands scan the entire index, which does not scale well. It would be much better if git status and related commands ran in O(number of changes) instead of O(size of repository). This would be a major effort, but the end result would be a much faster Git.

I would completely redesign the UX. For instance, the famous “git checkout $branch” vs “git checkout -b” vs “git checkout $filename” confusion could be completely eliminated by using a different verb for each of these things.

My work focuses on performance because that is what I enjoy and am good at. But I think UX work is often more important, and I wish that there were a way to correct some historical UX decisions.

Michael Haggerty just showed me git tbdiff, which is very useful when rebasing a large patch series. I also have to mention git shamend.


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 David Turner, Andrew Ardill and Johannes Schindelin.