Welcome to the 100th 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 May 2023 and June 2023.
The Git Rev News Reader Survey was announced in the previous edition with the goal to gather responses from the community to help improve Git Rev News. Unfortunately, there we got only 11 responses to the survey (among 250 visits). Compare this number to 3236 to 11498 responses to various Git User’s Surveys…
The results cannot be considered statistically significant, but here is what we have gathered so far:
There will be further analysis of the responses in the future. Thank you very much to everyone who participated in the Reader Survey.
Git participates in GSoC (Google Summer of Code) 2023
The following two contributors have been officially accepted to work on Git as part of the GSoC 2023:
Kousik Sanagavarapu will work on the “Unify ref-filter formats with other pretty formats” project. Kousik will be co-mentored by Hariom Verma and Christian Couder. Some details about his work on the project could be found in his blog.
Shuqi Liang will work on the “More Sparse Index Integrations” project. Shuqi will be mentored by Victoria Dye. Further details about the project and updates on progress can be found on Shuqi’s blog.
Congratulations to the accepted contributors!
Thanks also to the other contributors who applied and worked on micro-projects, but couldn’t be selected! We hope to continue to see you in the community!
Calvin Wan sent a 6 patch long series to clean up strbuf related
code. strbuf is a basic structure along with related functions,
implemented mostly in the “strbuf.c” and “strbuf.h” files, that is
used to manipulate character strings.
The issue was that over time some functions with dependencies to
other code had been added into those files, and Calvin’s series
wanted to get rid of these dependencies “with the goal of eventually
being able to stand up strbuf as a library”.
Most of the patches moved some functions to other files that were using them, and one of them removed the use of environment variables.
Junio Hamano, the Git maintainer, suggested that some functions that were moved to other files should be renamed so that they don’t start with “strbuf_” anymore, as they were not really string manipulating functions.
The series was also reviewed by Jeff King, Elijah Newren and Felipe Contreras, who overall liked it. They commented on some patches mostly to add some historical context or to ask for some clarifications.
Calvin sent
a version 2 of the series
that added a new patch at the beginning of the series to clarify the
purpose of the strbuf functions at the top of “strbuf.h”. The other
changes in this version were small clarifications in the commit
messages of some patches or in code comments.
Junio commented on the last patch of the series though. This patch
was supposed to remove the use of environment variables according to
its subject, but was in fact removing the dependencies of strbuf
functions on the comment_line_char global variable and adding a
new parameter to those functions instead.
Calvin sent a new version of this patch calling it a v3 even though the other patches in the series were not resent. Elijah reviewed this v2/v3 patch series and suggested some minor changes in some commit messages.
Calvin then sent a version 4 of the series with the commit message changes suggested by Elijah and Junio.
Both Eric Sunshine and Phillip Wood chimed in to comment on this
version. Eric suggested moving the comment added by the first patch
of the series further up in “strbuf.h” and making it clear that this
comment is for developers instead of mere users of the strbuf
functions. Phillip suggested simplifying the parameters of a
function where a new parameter was added by the last patch of the
series.
Calvin then sent a version 5 of the series which included the suggestions made by Eric and Phillip. Eric replied with some further small comments about the first and last patches of the series.
Calvin then sent a version 6 of the series with Eric’s suggestions, and a few weeks later a version 7 of the series to fix a few minor issues related to the release of Git v2.41.0 in the meantime. It looks like this series will be merged to the ‘master’ branch soon though.
Who are you and what do you do?
My name is John Cai, and I started to contribute to the project back in 2021. I also lead the Git team at GitLab, where we aim to improve Git and add features that will make the lives of GitLab users and Git users better.
What would you name your most important contribution to Git?
Adding a --batch-command mode to cat-file was the first feature that I
contributed to Git. It allows a single long running process to handle different
cat-file queries. Most developers wouldn’t take advantage of this, but for Git
servers it’s a nice feature.
What are you doing on the Git project these days, and why?
Things like documentation improvements, as well as working on some small features
that will optimize the server side of things. At GitLab we are currently
developing a system that will contain many ephemeral refs, so we recently added
options to git-pack-refs(1) that allow the caller to specify refs to exclude
from the packed refs file.
I still consider myself a bit of a newbie, but I love contributing however I can since Git is such an impactful project. Further, since our team interfaces with Git so much, I often notice opportunities for incremental improvements. Other times, we have explicit needs to add a feature or enhancement to support improvements to our Git data access layer in GitLab.
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?
Transition the project to a new refs backend! There have been plenty of great discussions around this – whether to go with the reftables backend or a new format of the packed-refs file. Swapping out the refs backend would be a huge undertaking, but well worth it, in my opinion.
What is your favorite Git-related tool/library, outside of Git itself?
When reviewing code, I’ve been using meld. I overall like the UI.
What is your toolbox for interacting with the mailing list and for development of Git?
I use GitGitGadget mostly, but also b4 is great for trying out patches locally.
What is your advice for people who want to start Git development? Where and how should they start?
It can definitely be intimidating since the codebase is so storied and technically deep. My suggestion is to just dive in and get started with something small – whether that be a documentation improvement or a code cleanup marked with TODO. Also, keep an eye out for bug reports on the mailing list. Fixing bugs also gives you experience with different parts of the code base.
Part of my intimidation is not knowing how people on the mailing list would respond to my contributions. Experiencing how helpful people were, and the overall warmth of the community removed a lot of the emotional barrier of contributing.
Also, it’s easy to read into tone in text-only communication, but the mailing list is full of people who genuinely want to help. Don’t let the fear prevent you from contributing! You’ll learn incrementally each time you send something to the list.
If there’s one tip you would like to share with other Git developers, what would it be?
Spend more time than you think you need to on crafting commit messages. It goes a long way to clearly state the need, and how the patch addresses the need.
Also, look for existing APIs in the codebase 😄.
Various
Light reading
Easy watching
Git tools and sites
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 Bruno Brito and Victoria Dye.