Welcome to the 73rd 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 2021.

• [QUESTION] Tracking HEAD changes?

  Yaron Wittenstein asked on the mailing list if there is "any possible way to track changes to HEAD using hooks". He said he would like to listen to events such as "pre-head-checkout" and "post-head-checkout", but thought that it was only possible using a file watch over the .git/refs directory.

  Jeff King, alias Peff, first replied that he thought there was no better way, and that it was also required to watch .git/HEAD. He also showed some code for Linux/inotify he uses to automatically run tests against the current commit:

  gitdir=$(git rev-parse --git-dir)
  # We need delete_self to pick up changes to HEAD (since it gets renamed
  # over), and "move" to pick up changes in the refs directories.
  inotifywait -qq -t 60 -e delete_self -e move -r "$gitdir/HEAD" "$gitdir/refs"

  Peff also recommended using Michael Haggerty's git-test tool for avoiding re-running tests against the same commits repeatedly.

  Then Peff replied to his previous email that Patrick Steinhardt also recently (since Git v2.28.0) implemented a new ref-transaction hook that can get triggered by updates to the ref that HEAD is pointing at.

  Yaron replied that this seems to do the trick, except the hook doesn't execute when switching branches. He found a work-around though by using the post-checkout hook in addition.

  Peff said that he thought the hook would be triggered when HEAD is updated by a branch switch, and wondered if that was a bug, a missing feature, or something intentional in the ref-transaction hook design.

  Patrick replied that the reason is that symrefs are not covered by the reference transaction mechanism itself, which existed before he implemented the new hook, and which the hook is using underneath. He also said that he should update the documentation to make it clearer what is covered by the hook and what's not.

  Yaron thanked Patrick for the clarification and asked if there were plans for the hook to be called when symrefs are updated. He also said it didn't seem intuitive to him that the index and working dirs are being updated, which calls the "post-index-change" hook, before the transaction is approved, which in turn calls the "ref-transaction" hook.

  Patrick replied that he didn't have plan for the hook to support symrefs, but wouldn't oppose such effort. About the order in which things were happening, he said that it is the way Git currently works and that the goal of the ref-transaction hook, which he worked on as part of his work for GitLab, was "to catch all reference updates such that one can coordinate across multiple git nodes the same action to assert they're moving from the same state to the same state, regardless of whether they're doing a git-push, git-merge or git-update-ref".

  Junio Hamano, the Git maintainer, further explained that "ref transaction is only about changes to the refs" and that "there is no such 'transaction' that treats a series of operations like object creation and index manipulation that may happen before a group of refs are updated as a single unit and make it atomic."

  Meanwhile Peff replied to Patrick's first explanation about why symrefs are not covered by the hook saying that it might be something that could be fixed. He also said that GitHub's custom repository replication mechanism does track symref updates, but uses a simple lock mechanism to get the state of the symrefs, while it uses a 3-phase commit based on custom code similar to the ref-transaction hook for normal refs.

  Yaron then summarized his understanding of how things work and asked if he was right. Peff replied that it matched his understanding.

• Git 2.31.0, 2.31.0-rc2, 2.30.2 and below for CVE-2021-21300, 2.31.0-rc1, 2.31.0-rc0
• Git for Windows 2.31.0(1), 2.31.0-rc2(1), 2.31.0-rc1(1), 2.31.0-rc0(1), 2.30.2(1)
• Bitbucket Server 7.11
• GitHub Enterprise 3.0.2, 2.22.8, 2.21.16, 3.0.1, 2.22.7, 2.21.15, 2.20.24
• GitLab 13.10, 13.9.4, 13.8.6, and 13.7.9, 13.9.3, 13.9.2, 13.8.5 and 13.7.8, 13.9.1
• GitKraken 7.5.2
• GitHub Desktop 2.6.6, 2.6.5, 2.6.4

Various

• Git clone vulnerability announced by Taylor Blau on GitHub Blog, and A vulnerability in Git by Jake Edge on LWN.net.
• Highlights from Git 2.31 by Taylor Blau on GitHub Blog.
• Congratulations to Joey Salazar and Charvi Mendiratta who successfully completed their Outreachy internship working on Git!

Light reading

• Optimizing git’s merge machinery, #1 and #2 by Elijah Newren on Palantir Blog.
• How Does Git Work? by Julie Kent.
• Git is my buddy: Effective Git as a solo developer by Mikkel Paulson.
• How to Utilize Submodules within Git Repos: One Solution When the Primary Code Can be Open Source, but Specific Content Needs to be Private, by Paige Niedringhaus on Bits and Pieces blog (a Medium site).
• How to use .mailmap file in git repository by Lukáš Mešťan (2020).
• What is Trunk Based Development? A Different Approach to the Software Development Lifecycle by Kealan Parr on freeCodeCamp. This approach was also one of those described in Patterns for Managing Source Code Branches by Martin Fowler, which was mentioned in Git Rev News Edition #63.
• Improving large monorepo performance on GitHub by Scott Arbeit on GitHub Blog, in the Engineering section.
• Hacking the git shell prompt by Mark Dominus describes a hack creating a generic mechanism for abbreviating or transforming the branch name in the prompt.
• Boost Your Programming Skills by Reading Git's Code by Jacob Stopak on freeCodeCamp.
• How To Set Up Continuous Integration With Git and Jenkins by Suparna Khamaru on LambdaTest Blog.
• Store your Kubernetes Secrets in Git thanks to Kubeseal. Hello SealedSecret! by Aurélie Vache on Dev.to. More generic solutions for storing secrets in Git repository were described in Git Rev News editions #39 and #57, among others.

Git tools and sites

• Project GITenberg is a Free and Open, Collaborative, Trackable and Scriptable digital library. It leverages the power of the Git version control system and the collaborative potential of GitHub to make books more open. The books in this project originate from the work of Project Gutenberg, a volunteer effort to digitize and archive cultural works, mostly the full texts of public domain books.
• ungit is a Git command-line UI with text editor integrations, that utilizes your web browser as graphical interface. It is intended to make Git easier to use. In this it is somewhat similar to no longer actively developed Easy Git.

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 Ævar Arnfjörð Bjarmason and Matheus Tavares Bernardino.