Git Rev News: Edition 47 (January 23rd, 2019)
Welcome to the 47th 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 December 2018.
Ævar Arnfjörð Bjarmason replied to a patch that Jonathan Nieder had sent to the mailing list. He suggested using the standard commit-reference format documented in SubmittingPatches in the commit message of the patch.
Using the standard format would have produced:
92068ae8bf ("stripspace: respect repository config", 2016-11-21)
while Jonathan’s patch contained:
v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
The main difference is that the former starts with an abbreviated object id, while the latter starts with an output from
Ævar gave an example of him previously looking for a commit using
git log --grep=0386dd37b1and not finding it because Jonathan had not used the standard format.
Ævar also wondered if “we should have some mode where
--grep=<commitish>will be combined with some mode where we try to find various forms of
<commitish>in commit messages, then normalize & match them…”
Duy Nguyen replied to that by suggesting we use email style trailers like
In-Reply-To: ...or even
Fixes: ...to refer to related commits, which could make sense as we already use
Signed-off-by: User <email>trailers and some other similar trailers in commit messages.
Gábor Szeder also replied to Ævar saying that the
%h (%s, %ad)is even better and more widely used than the standard
%h ("%s", %ad)as the former avoids useless double quotes around the commit title.
Jeff King, alias Peff, then commented to Ævar’s suggestion about a new mode for
--grep=<commitish>. He gave examples of other tools that work better with the standard format:
web interfaces like GitHub have learned to replace an abbreviated object id with a link to a page displaying the object,
terminals makes it easy to select object ids, but don’t understand output from
Peff acknowledged that the format with an output from
git describehas some benefits:
As far as I can tell, the main advantage of using
v2.11.0-rc3~3^2~1over its hex id is that it gives a better sense in time of which Git version we’re talking about. The date in the parentheses does something similar for wall-clock time, but it’s left to the reader to map that to a Git version if they choose.
But he thought that they were not worth the disadvantages “as in the rare instance that I care about the containing version, it’s not a big deal to use
git tag --contains”.
He suggested anyway using something like:
1234abcd (the subject line, 2016-01-01, v2.11.0)
which adds a version after the date, “if we really want to convey that information”. And he proposed some reasonable rules for this new format.
Jonathan replied to Peff’s suggestion by discussing the possible ambiguities in what the tag name is referring to. This led Jonathan to prefer using trailers like
Fixes: ...as Duy had suggested, saying they have been working well for the Linux kernel project.
In a separate reply to Duy’s email, Jonathan copied relevant documentation from the Linux kernel project where they specify a trailer that looks like:
Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
Jonathan then proposed a patch to the Git Documentation that would make the Git project adopt a similar policy.
Peff replied to Jonathan that using
Fixes: ...trailers is a good idea but that “there are many other reasons to refer to another commit in prose (or even outside of a commit message entirely)”.
Jonathan, Peff and Ævar discussed a bit more, and Jacob Keller chimed in, but in the end it doesn’t look like any change has been decided.
- JGit 4.5.5, 4.7.7, 4.9.8, 4.11.6, 5.1.5, 5.2.1
- Gerrit Code Review 2.9.5, 2.10.8, 2.11.12, 2.12.9, 2.13.12, 2.14.18, 2.15.8, 2.16.2, 2.16.3
- GitHub Enterprise 2.15.5, 2.14.12, 2.13.18
- GitLab 11.6.5, 11.6.4, 11.5.7 and 11.4.14, 11.6.3, 11.6.2, 11.6.1, 11.5.6 and 11.4.13, 11.6
- GitKraken 4.2.0
- GitHub Desktop 1.6.0
- Security vulnerabilities in JGit and Gerrit:
- Gerrit issue 10201: When protocol v2 was enabled and used, Gerrit would make all refs visible to the calling user. Support for protocol v2 was removed in Gerrit 2.16.2, and the issue was fixed in JGit versions 5.1.5 and 5.2.1.
- Gerrit issue 10262: In protocol v0 stateless transport, it was possible to fetch anything that is pointed to by any ref (using fetch-by-sha1), as long as the attacker could guess the object name. The issue was fixed in JGit versions 4.5.5, 4.7.7, 4.9.8, 4.11.6, 5.1.5 and 5.2.1, which were included in Gerrit versions 2.9.5, 2.10.8, 2.11.12, 2.12.9, 2.13.12, 2.14.18, 2.15.8 and 2.16.3.
- Outreachy interns working on Git have been blogging about their internship:
- AsciiDoc, the markup language used by Git’s manual and other documentation, will get an official specification under the Eclipse Foundation.
- Google is seeking open source projects for Google Summer of Code 2019. The deadline to apply is February 6 at 20:00 UTC, chosen organizations will be announced on February 26. Git Development Community is interested.
- GitLab Serverless launched Dec. 22.
- New year, new GitHub: Announcing unlimited free private repos and unified Enterprise offering (the former with up to three collaborators per repository).
- Git explained: Git Concepts and Workflows by Edwin Kempin
- Gerrit explained: Gerrit Concepts and Workflows by Edwin Kempin
- A tale of 132 e’s and the [E]nd of eeeee by Iliana Weller, about e30e/e98e GitHub repository and its history
- How to teach Git by Rachel M. Carmena
- How To Use Git: A Reference Guide by Lisa Tagliaferri from DigitalOcean
- 8 Productivity Tips for GitHub by Darren Burns
- Something Someone Somewhere Uses… Sometimes by benjaminadk, about gitmoji
- A new free-software forge: sr.ht [LWN.net] by Jake Edge; this service was covered in previous edition of Git Rev News
- Monorepos: Please don’t! by Matt Klein
- Monorepo: please do!, response by Adam Jacob
- see also Advantages of Monolithic Version Control by Dan Luu (Git Rev News: Edition #4) and Monorepos in Git by Stefan Saasen (Git Rev News: Edition #9)
- and also splitsh/lite (Git Rev News: Edition #16) and Lerna (Git Rev News: Edition #43) tools for monorepos
- Writing Good Commit Messages by Ben Hoyt (2018)
- Useful Tips for writing better Git commit messages by Egwuenu Gift (2018)
- 1296: Git Commit – explain xkcd (2013)
- How to manage binary blobs with Git by Seth Kenlon (2016)
- Migrating Internet Archive to Kubernetes – slides from presentation at KubeCon 2018; slides #35 and later are about how Git is used at archive.org
Git tools and sites
- OneDev Open source git server with unique features such as language aware code search and navigation, source/diff annotation for code discussion and comprehension, customizable issue field and workflow, write protection for branches/tags/files, etc.
- gitmoji – An emoji guide for your commit messages
This edition of Git Rev News was curated by Christian Couder <email@example.com>, Jakub Narębski <firstname.lastname@example.org>, Markus Jansen <email@example.com> and Gabriel Alcaras <firstname.lastname@example.org> with help from Johannes Schindelin, Robin Shen and David Pursehouse.