Welcome to the 49th 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 February 2019.
test-lib: make ‘--stress’ more bisect-friendly
--stress is an option that can be passed to a test script from the
Git test suite to try to reproduce rare failures in the test script
by running it many times in parallel.
Gábor Szeder had initially implemented this option starting last December based on a script that Jeff King, alias Peff, had developed and mentioned on the mailing list.
That first iteration had been reviewed by Peff, Ævar Arnfjörð Bjarmason and Junio Hamano, and was followed by a second iteration also reviewed by Peff.
A third and fourth iteration were sent with only minor changes. The latter then got merged last January, so the feature was released in Git 2.21.0.
On February 8th Gábor sent a patch to improve on top of his previous
work on --stress. The goal was to make it easier to use the
--stress along with git bisect to find the first commit that
introduced a test failure when the test failure is not easy to
reproduce.
Specifically, the patch was addressing two issues with
--stress. The first one is that --stress runs the test script
endlessly when the test doesn’t fail. This is fixed with a new
--stress-limit=<N> option “to repeat the test script at most N
times in each of the parallel jobs, and exit with success when the
limit is reached”.
The second issue is that when the test script used with --stress
fails, it exits with a success error code. This is addressed by
making it exit with a failure error code in this case.
With the improvement, it is possible to automatically find the
commit that introduced a flakiness in for example t1234-foo.sh,
using something like:
$ git bisect start origin/pu master
$ git bisect run sh -c 'make && cd t && ./t1234-foo.sh --stress --stress-limit=300'
Gábor and Peff then discussed a few details. Regarding how to select a
good N to pass to --stress-limit=<N>, Gábor suggested running the
test script with --stress 3-5 times to trigger the failure, taking
the highest repetition count that was necessary for the failure and
multiplying it by 4-6 to get a round number”.
Gábor later sent a subsequent patch
to fix a minor issue in his previous patches, as it seems that some
shells require the ! character to start a non-matching pattern
bracket expression instead of ^ that he had used.
These improvements to the --stress option made it in the Git
2.21.0 release too.
Even more recently Johannes Schindelin, alias Dscho, sent a small patch series to improve on the previous work by:
--stress-limit=<N> imply --stress--stress-jobs=<N>The goal is to avoid mistakenly using --stress=<N> when one wants
to limit the number of number of times the test script is run (which
should be done using --stress-limit=<N>).
Dscho then sent a second version of his patch series with a few improvements.
These patches were reviewed by Junio, Eric Sunshine, Peff and Gábor. The changes have been merged to the ‘next’ branch and are planned to be merged in the ‘master’ branch soon.
Various
Videos of the Git Merge 2019 conference (January 31th and February 1st 2019 in Brussels, Belgium) are now available.
The Gerrit User Summit 2019 will take place in Gothenburg 29-30 August, hosted by Volvo Cars. The event is free but seats are limited. For the first time also the community opens the 5 days Hackathon 24-28 August, same location, to everyone: the only requirement is to be willing to learn and contribute to the JGit or Gerrit Code Review project.
Google is creating a project aimed at improving OSS projects documentation: Season of Docs 2019. Mentoring organizations can begin submitting applications to Google on April 2, 2019.
Light reading
Redesigning Github repository page by Nikita Prokopov describes how the author would have changed the design.
Write yourself a Git! by Thibault Polge is an attempt at explaining the Git version control system from the bottom up, that is, starting at the most fundamental level moving up from there. All it takes to understand Git internals is to reimplement Git from scratch in exactly 503 lines of very simple Python code.
10 Git Commands You Should Know; Plus tips to save time with Git by Jeff Hale.
Git hacks you should know about by Ankur Biswas; most of these is a regular workflow stuff, though (and you need to take care as some of commands rewrite history).
Data Versioning by Emily Gorcenski identifies four key axes on which machine learning systems have a notion of version along with some brief recommendations for how to simplify it a bit.
Git tools and sites
Git Interactive Rebase Tool is an improved sequence editor for Git interactive rebase by MitMaro.
radicle is a peer-to-peer stack for code collaboration based on Git and IPFS.
Git-graph by Henri-Olivier Duché can help you “Learn Git fast and well - by visualizing the inner graph of your Git repositories”.
Pachyderm is designed to enable sustainable data science workflows via a language-agnostic system for data versioning with data pipelining. Similar tools, namely DVC (Data Version Control) and Meltano, were described in Git Rev News Edition #42.
git ready: learn Git one commit at a time; tips are split into beginner, intermediate and advanced. Latest tip is from 2015, though.
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Gabriel Alcaras <gabriel.alcaras@telecom-paristech.fr> with help from Luca Milanesio <luca.milanesio@gmail.com>.