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.
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.
[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 of tee, 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 where tXXXX-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.
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 use mutt to write contents.
When sending patches, I still use mutt 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 using
compiledb 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.
Various
Light reading
av, a CLI tool
to help with managing stacked PRs on GitHub.
Git tools and sites
git clone.
Supports GitHub, GitLab, Bitbucket, and Sourcehut (sr.ht).
Written in JavaScript for Node.js, under MIT license.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.