Welcome to the 67th 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 August 2020.

• GSoC 2020 End

  The Google Summer of Code 2020 officially ended on September 8, 2020. Congratulations to the three students who were mentored by the Git community, as they successfully passed all the evaluations! Their final reports and code submissions are available:

  • Hariom Verma, who was mentored by Heba Waly and Christian Couder, worked on "Unify ref-filter formats with other --pretty formats".

  • Abhishek Kumar, who was mentored by Jakub Narębski and D. Stolee, worked on "Implement Generation Number v2".

  • Shourya Shukla, who was mentored by Kaartic Sivaraam and Christian Couder, worked on "Convert submodule to builtin".

• [RFC PATCH 0/2]extend --abbrev support to diff-patch format

  Đoàn Trần Công Danh sent a small RFC patch series that makes the diff machinery, which is used by git diff and similar commands, support the --abbrev option when it shows a patch.

  In addition to the familiar --patch format, which is used when showing regular diffs in a way similar to the unified format of the Unix diff command, the diff machinery can produce the --raw format output to show object names before and after the change for each path like this:

  :100644 100644 86e5411f39 f1b1bc8aa0 M  Makefile
  

  In the --patch format, object names before and after the change appear on the index line, which looks like this:

  index 4adb9ce124..67d9801da3 100644
  

  The --abbrev option used to control the abbreviation of the object names in the --raw format but did not affect those shown on the index line in the --patch format. Đoàn's patch series makes the option control both.

  In the cover letter of his RFC patch series, Đoàn explained how the changes would improve his workflow when dealing with patches. But Junio Hamano and Jeff King, alias Peff, replied saying that they had trouble understanding the purpose of the series from the explanations in the cover letter.

  After a discussion with Peff and Junio, it turns out that using the --full-index option is a better approach to help Đoàn's workflow (the option was specifically designed to ensure that the index line in the --patch format can be used to exactly identify the objects involved in the change to help the users, which was what Đoàn's workflow wanted). However, a consensus was reached that Đoàn's patch series was worth moving forward, because it improved consistency between the diff formats.

  So Đoàn sent a version 2 of his patch series with only changes in the cover letter and in the commit message of the second patch.

  Junio replied to the first patch of the series though. This patch changed how --no-abbrev was dealt with. Junio asked for clarifications in the commit message, especially about why the patch was necessary.

  So Đoàn sent a version 3 of his patch series with only changes in the commit message of the first patch. After further discussion with Junio, it appears that the patch was not actually necessary.

  In the meantime though Gábor Szeder found that the tests in the second patch were failing when run with GIT_TEST_DEFAULT_HASH=sha256. This setting makes Git use the SHA-256 hash algorithm instead of the usual SHA-1 hash algorithm for object names.

  A discussion about the best approach to fix this then followed between Đoàn, Junio and Brian M. Carlson, who has been working for a long time on implementing support for SHA-256 in Git.

  Đoàn eventually sent a version 4 of his patch series, where the first patch of his version 3 had been discarded, but a new patch to improve handling of SHA-256 object names in the tests replaced it.

  Junio and Đoàn discussed further improvements to the commit messages of both patches. Then Đoàn sent a version 5 taking these improvements into account.

  The patch series has since been merged into the 'master' branch.

• Who are you and what do you do?

  I'm just another average developer addicted to an exotic environment. Outside of my $dayjobs, I maintain Git and some other packages for VoidLinux.

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

  I would consider fixing remaining problems with musl libc my most important contributions to Git, since I mostly stay inside my musl box these days.

• What are you doing on the Git project these days, and why?

  I mostly watch for sideline these days, since I'm busy with other things. Occasionally, I jump in one or two discussion since that topic looks relevant to me. Sometimes, I write a patch or two to support my own jobs.

• 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?

  I don't have anything specific in mind, except the transition into the new hash algorithm, brian m. carlson has done a very good job, and I understand the transition would require a long transition period, testing, a lot of testing.

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

  The diff to merge-base notation (upstream...fork) of the diff family. This has been floating in the mailing list for a while, and I won't waste this opportunity to not mention it again.

  There's an on-going change from Denton Liu to support --merge-base into the diff family. Hopefully, people can retrain their brain-muscles to use this new option instead.

• GitHub Enterprise 2.22.0, 2.21.7, 2.20.16, 2.19.22, 2.21.6, 2.20.15, 2.19.21
• GitLab 13.4, 13.3.6, 13.3.5, 13.3.4, 13.3.2, 13.3.1
• Bitbucket Server 7.6
• GitKraken 7.3.2, 7.3.1, 7.3.0
• GitHub Desktop 2.5.5

Events

• The first Git Contributors' Inclusion Summit happened on Monday, September 14th, and Tuesday, September 15th. It was attended by around 30 people. Some notes were taken but it's not clear if they are going to be publicly available.

Various

• Set the default branch for newly-created GitHub repositories on GitHub Blog.
  On October 1, 2020, if you haven't changed the default branch for new repositories for your user, organization, or enterprise on GitHub, it will automatically change from master to main. You can opt out of this change at any time. Existing repositories will continue to have the same default branch they have now.

• 'There is no way we can keep coding local': GitPod's cloud development platform released into sunlight of open source -- The Register chats with co-founder Sven Efftinge.

• Discussions have been going on about the Git project participating in the next Outreachy round. So far 3 projects have been proposed.

Light reading

• Arista Networks, a Fortune 500 company, has rolled out mandatory commit signing across their Git repositories. Read about their journey at https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ and learn about how they:

  • Manage code signing keys across a large company
  • Enforce that all commits are signed
  • Audit Git repositories to ensure that no unsigned commits are added.

• Guillaume Papin in his development notes on a compilation database (a concept that includes, but is not limited to a JSON Compilation Database) includes section on Git as one of (and at this time the only) case studies on open source projects.

  There is a patch by Philippe Blain to add support for generating a JSON compilation database to Git's Makefile. It is currently merged into 'next'.

• Keith Peters writes how to create your own Git-based Wiki to save information that one might need later. The idea is to make use of the fact that many Git hosting sites render Markdown on-line, by storing the data in interlinked Markdown files -- the article proposes the template to use.

• Patterns for writing better git commit messages by Helder Burato Berto, with references to other articles, and a git commit template.

• Learn Enough Git and Github to take part in the Weekly Challenge by Dave Cross (not intended as "beginners guide to Git and Github").

• Git Concepts and Workflow for Beginners by Juan Cruz Martinez on Live Code Stream.

Git tools and sites

• ugit: DIY Git in Python is a tutorial to help learn about Git internals by building an implementation of Git in Python.

• gitoxide (gix) is a command-line interface (CLI) to access Git repositories. It's written to optimize the user-experience, and perform as good or better than the canonical implementation.

  It provides an idiomatic, lean, fast and safe pure Rust implementation of Git, and it also provides an easy and safe to use API in the form of various small crates for implementing your own tools.

• grokmirror-2.0 is a Git mirroring software announced by Konstantin Ryabitsev on the Git mailing list. It was developed by kernel.org for their own use.

• GitQlient, pronounced as git+client (/gɪtˈklaɪənt/), is a multi-platform Git client written with Qt, originally forked from QGit.

  Related project is GitQlientPlugin, the project to build an integrated QtCreator plugin of GitQlient.

• Graphtage: A New Semantic Diffing Tool is a command line utility and underlying library for semantically comparing and merging tree-like structures such as JSON, JSON5, XML, HTML, YAML, and TOML files. You can even compare files that are in two different formats. When paired with the PolyFile tool you can semantically diff arbitrary file formats.

• Sourcetrail is a free and open-source cross-platform interactive source explorer, that helps you get productive on unfamiliar source code. It currently supports C, C++, Java and Python.

• git-in is a small Python script to import a message or an entire thread from a mailing list to an IMAP mailbox. Very useful when you are not subscribed to the list but want to answer an email from the list, while being be able to quote parts of the message.

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 Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Ethan Rahn, Philippe Blain and Junio Hamano.