Git Rev News: Edition 115 (September 30th, 2024)
Welcome to the 115th 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 months of August and September 2024.
Discussions
General
-
Git Merge 2024 conference and Contributor’s Summit 2024
The Git Merge conference happened on September 19th and 20th in Berlin, hosted by GitButler and GitHub.
The first day consisted of talks and an afterparty in the evening sponsored by GerritForge.
On the second day, there was the Contributor’s Summit in parallel with breakout unconference sessions.
-
Git participated in GSoC (Google Summer of Code) 2024
All the contributors have successfully passed their final evaluation and published a final report:
-
Jialuo She worked on the Implement consistency check for refs project. He was mentored by Karthik Nayak and Patrick Steinhardt. The final report can be found on his website.
-
Chandra Pratap worked on the Move and improve reftable tests in the unit testing framework project. He was mentored by Patrick Steinhardt and Christian Couder. The final report can be found on his website.
-
Ghanshyam Thakkar worked on the Move existing tests to a unit testing framework project. He was mentored by Christian Couder and Kaartic Sivaraam. The final report can be found on his website.
Congratulations to the contributors and their mentors!
-
-
Git will participate in the next Outreachy round
Git applied to participate in the next Outreachy round from December 2024 to March 2025 and was accepted. Two projects are proposed:
-
“Convert unit tests to use the clar testing framework” which will be mentored by Patrick Steinhardt and Phillip Wood.
-
“Finish adding a ‘os-version’ capability to Git protocol v2” which will be mentored by Christian Couder.
See this Outreachy webpage for more information about the application process for contributors.
-
Reviews
-
[PATCH] tests: drop use of ‘tee’ that hides exit status
Junio Hamano, the Git maintainer, sent a patch removing uses of the
tee
command from test scripts. tee(1) is a shell command that duplicates its input to both its output and to one or more files. The issue was that in some test scripts it was used after a pipe to directly duplicate the output of a Git command, so using a format like:git COMMAND OPTIONS... | tee FILE...
However, it’s not a good idea to use a pipe after a Git command because pipes discard the exit code of the command before them, so the standard (Unix) shell behaviour is that the exit code of the whole sequence is simply the exit code of the last command of a pipe sequence, here
tee
. In Git tests though, we wouldn’t want a test to pass if the Git command fails when it should succeed.[For shell intimates: there are ways to override this default behaviour, such as the
pipefail
option, or named pipes, but there are a number of reasons, like shell portability and making it easy to understand small parts of the code, why Git developers try to avoid using those features in the Git codebase.]As there was no reason to hide the exit code of the Git commands in the tests that used
tee
, Junio’s patch basically just replaced| tee
with a simple>
redirection.Rubén Justo replied to Junio suggesting a wording improvement in the commit message, but otherwise agreeing with the patch.
Johannes Schindelin, alias Dscho, also replied to Junio saying that having something that duplicates the output of the Git command to standard output could still be useful for debugging, especially when dealing with CI failures. He showed an implementation of a
redirect_and_show()
helper function that could perhaps be used instead oftee
, but agreed that it might be overkill and hoped that having more unit tests written in C could help.Jeff King, alias Peff, replied to Dscho saying that a better help for debugging CI failures might be to have a way to automatically save the state of the test directory, called
trash directory.tXXXX-YYYY
wheretXXXX-YYYY
is related to the name of the test script.Junio also replied to Dscho saying that a simple
cat FILE
instruction could be added after the lines where| tee
was replaced with a redirection to make sure the Git command output appeared on standard output. Junio also agreed with Peff that saving the state of test directories would be best to debug CI failures.A version of Junio’s patch taking into account the wording improvement suggested by Rubén was eventually merged.
Developer Spotlight: Jialuo She
Editor’s note: We’re starting a new initiative in Git Rev News where we interview recent GSoC/Outreachy students to get their reflections on completing their projects. Feel free to share any thoughts or feedback you might have!
-
Who are you and what do you do?
My name is Jialuo She. I find it quite challenging to select an English name for myself, so I decide to leave it as is. However, you can simply call me “Luo(/lwɔː/)”. I am currently employed at NVIDIA as a Tegra System Architect. In this role, I am responsible for developing the verification infrastructure for complex full-chip features, such as CPU-GPU cache coherency. So my daily job is unrelated to Git. In my spare time, I continue my GSoC work to implement consistency checks for refs.
-
How did you initially become interested in contributing to Git, and what motivated you to choose it as your GSoC project?
When I was a student, I read the book “Pro Git” to learn how to use Git in my daily development process. One day, I found a tutorial that teaches how to write a mini Git step by step, and I really appreciated the design of Git.
As I was approaching my graduate school graduation, I hoped to use the opportunity provided by GSoC to do something meaningful for the long term. Since I felt that I had an understanding of Git’s internal principles, believing that my chances of being selected would be much higher. When I saw the “Implement consistency check for refs” project, I became very interested and resolutely chose Git.
-
How do you balance your contributions with other responsibilities like work or school?
As a newcomer, contributing to Git can be particularly time-consuming due to unfamiliarity with the overall codebase. I would dedicate an evening to responding to review feedback, which forces me to think about how to make improvements, and then I would code over the weekend. Of course, if there were urgent situations at work or life, I would have to postpone my contributions to Git. I feel there’s no need to think about balancing because it happens naturally.
-
What was your biggest takeaway or learning from GSoC that you now apply regularly in your work?
After participating in GSoC, I begin to consider whether my commit sequence is clear and understandable when writing code at work. I also become more stringent with myself regarding commit messages, ensuring they clearly explain the background, motivation, and implementation details.
-
What was the biggest challenge you faced during your contributions to Git, and how did you overcome it?
When building the ref consistency check infrastructure, I encountered an exceptionally long review process that lasted about three months. It was quite frustrating because there was no positive feedback compared with other participants. Then I reflected on myself, wondering why I was always comparing myself to others instead of focusing on what I was doing. So, I adjusted my mindset.
-
Have you thought about mentoring new GSoC students?
If I have the opportunity and time, I would definitely mentor GSoC students. I am very grateful to my mentors, Patrick and Karthik, for introducing me to the Git community and enabling me to continue contributing after completing GSoC. I hope that one day I can also ignite the passion in others.
-
If you could remove something from Git without worrying about backwards compatibility, what would it be?
The write and read support for symlink symrefs.
-
What is your favorite Git-related tool/library, outside of Git itself?
I very much like the GitLens tool when using VSCode. By using this tool, I hardly use the bare
git blame
command. -
What is your toolbox for interacting with the mailing list and for development of Git?
When reviewing patches, I will firstly use
b4
or simply fetch the branch stored in Junio’s tree, and then I will see the diffs just in the VSCode. To reply to a patch, I download the raw email and usemutt
to write contents. When sending patches, I still usemutt
to make the environment as simple as possible to improve efficiency.I develop Git using VSCode and the clangd language server. I generate the
compile_commands.json
file usingcompiledb make
. I believe this is one of the best development approaches available today, offering excellent code suggestions, completions, and static analysis. -
How do you envision your own involvement with Git or other open source projects in the future?
I hope to complete the implementation of all ref consistency checks. Additionally, I aim to further familiarize myself with the Git codebase related to refs, follow the development of the reftable backend, and participate in more reviews.
-
What is your advice for people who want to start Git development? Where and how should they start?
In my opinion, the barrier to starting contributions to Git is relatively high because Git doesn’t have something like “good first issue” labels. Therefore, I believe the best approach is to participate in mentoring programs or continue work from certain mentoring programs as a student.
-
Would you recommend other students or contributors to participate in the GSoC, or other mentoring programs, working on Git? Why? Do you have advice for them?
I highly recommend that students integrate into the Git community through mentoring programs. These programs provide basic ideas to help you get started and contribute to Git. Working on Git is an amazing experience, allowing you to be guided by many experienced contributors, improve your code quality standards, and enhance your communication skills.
As for advice to participants, I believe the most important thing is not to think of the project merely as a resume booster. Instead, let your passion shine through and stay at the community after mentoring programs.
Other News
Various
- Radicle 1.0.
Radicle is a peer-to-peer, local-first code collaboration stack built on Git. Radicle was first mentioned in Git Rev News Edition #49, then in Edition #70, #86, and #110 - where one can find similar and related tools. - git-scm.com is now a static website
by Johannes Schindelin on the Git mailing list.
Moving git.github.io, Git Developer Pages and Git Rev News’ website into git-scm.com is discussed in GitHub issue #729.
Light reading
- Why GitHub Actually Won:
How GitHub actually became the dominant force it is today, from one of its cofounders.
Written by Scott Chacon on GitButler Blog.
Nice companion to various articles on Git history, like the latest A Git story: Not so fun this time in Git Rev News #113 - in #113 you can also find links to other editions with links to other retellings of the Git history. - Rethinking code reviews with stacked PRs
on Aviator blog by Ankit Jain (also available on DEV.to,
published by Ibrahim Salami. Aviator provides
av
, a CLI tool to help with managing stacked PRs on GitHub.- Stacked Pull Requests, also under the name Stacked Diffs, were most recently mentioned in Git Rev News Edition #111, where you can find links to other editions with other articles, and to related tools.
- See also Stacked PRs CLI Product Comparison (Public) Google Sheet spreadsheet.
- Contrast Patterns for Managing Source Code Branches, which strongly recommends patterns that are best suited to Continuous Integration, first mentioned in Git Rev News Edition #63, and Ship / Show / Ask: A modern branching strategy, mentioned in Edition #79.
- Git With Python HowTo: GitPython Tutorial And PyGit2 Tutorial by Marco Antonio Carcano on his blog ‘The grimoire of a modern Linux professional’.
- Beyond “Commit” and “Push”: 5 Advanced Git Features You Should Know by Bruno Brito on GitTower Blog. Covers git-bisect, git-rerere, gitattributes, git-notes, and git-worktree.
- Mastering Tower (Windows Edition) and Mastering Tower (Mac Edition) by Bruno Brito on GitTower Blog. Tower is a proprietary Git client for Mac and Windows, with 30-day free trial.
- Git bisect run techniques by Victor Engmark on paperless.blog.
- Semantic Versioning with GitVersion (GitFlow) by Raul Naupari on his blog; Featured on daily.dev, also available on DEV.to.
- Host your own Radicle seed node by Eduard on Ed’s Site. Also available on DEV.to.
- Creating a Git commit: The Hard Way (with low-level plumbing commands) by Aryan Ebrahimpour on Avestura’s Personal Website.
- My Git cheatsheet - a list of some useful commands, as a cheatsheet or a simple reminder to keep and share. Written by Pierre-Yves Lapersonne on his French and English pylapp blog in the fediverse (write.as).
Git tools and sites
- b4 is a tool created to make it easier for project developers and maintainers to use a distributed development workflow that relies on patches, e-mail and distribution lists for code contributions and review (like those used in Linux kernel development). This tool was first mentioned in Git Rev News Edition #61; you can find links to various articles and posts about this tool in Edition #61, #91, #95, #107 and #109. Written in Python, under GPL-2.0 license.
- Phabricator.KDE.org is KDE’s desktop environment task management system.
It was used for patch review and other functions in the past, but KDE has since transitioned to GitLab,
at https://invent.kde.org. Bug tracking is done using https://bugs.kde.org.
Phabricator is still used for task tracking by KDE until this functionality is migrated to GitLab.
- Phabricator is/was a suite
of web-based development collaboration tools, which includes a code review tool called Differential,
a repository browser called Diffusion, a change monitoring tool called Herald,
a bug tracker called Maniphest, and a wiki called Phriction.
Phabricator is no longer actively maintained by Phacility since June 1, 2021. This tool was mentioned in Git Rev News Edition #13. Written in PHP, under Apache 2.0 license. - Phorge is a community-maintained fork of Phabricator, public since Sep 7, 2022. It seems to be actively developed.
- Phabricator is/was a suite
of web-based development collaboration tools, which includes a code review tool called Differential,
a repository browser called Diffusion, a change monitoring tool called Herald,
a bug tracker called Maniphest, and a wiki called Phriction.
- nb-clean cleans Jupyter notebooks of cell execution counts, metadata, outputs, and (optionally) empty cells, preparing them for committing to version control. Written in Python, under short ISC license.
- av (Aviator) is a command-line tool that helps you manage your stacked PRs on GitHub. Written in Go, under MIT license.
- Stacked PRs CLI Product Comparison (Public)
is a Google Sheet spreadsheet by Aviator, listing various stacked PR/stacked diff tools:
- ghstack in Python,
- gh-stack in Rust - no longer developed,
- git-branchless in Rust (mentioned in Git Rev News Edition #76, #90, #93, #98, and #106),
- git-branchstack in Python,
- git-chain in Rust,
- git-machete in Python
- also available as a plugin for the IntelliJ Platform products,
- git-ps-rs - Git Patch Stack in Rust,
- git-series in Rust (first mentioned in Git Rev News Edition #18, with a link to the presentation in #19),
- git-stack in Rust,
- graphite-desktop (formerly graphite-cli) in JavaScript/TypeScript - no longer actively developed,
- Sapling SCM Git-compatible source control system by Facebook (mentioned in Git Rev News Edition #93),
- spr - Stacked Pull Requests on GitHub, in Go,
- Stacked Git (StGit) in Rust (mentioned in Git Rev News Edition #17, #21, and #74, and finally presented as a tool in #93).
- degit is a CLI tool
that makes copies of Git repositories faster than ordinary
git clone
. Supports GitHub, GitLab, Bitbucket, and Sourcehut (sr.ht). Written in JavaScript for Node.js, under MIT license. - GitVersion is a tool that generates a Semantic Version number based on your Git history. Available as Continuous Server pipeline, CLI tool, MSBuild task, and software library. Written in C#, under MIT license. Works on Windows, Linux, and Mac.
- ugit: DIY Git in Python is a tutorial on Git internals, where you learn about how Git works on the inside by trying to implement (micro) Git in Python.
Releases
- Git 2.47.0-rc0, 2.46.2, 2.46.1
- Git for Windows 2.47.0-rc0(1), 2.46.2(1), 2.46.1(1)
- GitHub Enterprise 3.14.1, 3.13.4, 3.12.9, 3.11.15, 3.10.17
- GitLab 16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10, 17.4.1, 17.3.4, 17.2.8, 17.4, 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10, 16.11.9, 17.0.7, 17.3.2, 17.2.5, 17.1.7
- GitKraken 10.3.0
- GitHub Desktop 3.4.5, 3.4.4
- Garden 1.8.0
- Git Cola 4.8.2
- GitButler 0.12.26, 0.12.25
Credits
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 Jialuo She, Josh Steadmon and Štěpán Němec.