Welcome to the 116th 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 September and October 2024.
fatal from submodule status --recursive when used with grep -q
Matt Liberty reported that when he tried using
git submodule status --recursive | grep -q "^+" on a repo with
a submodule, he got an error message like “fatal: failed to recurse
into submodule XXX”, where XXX is the name of the submodule.
He expected no error message, no output and a 0 exit code from the
whole command line as it should have succeeded. He guessed that Git
didn’t like that grep when used with -q exits immediately
(without printing anything) when there is a match.
Phillip Wood replied to Matt saying he assumed that grep’s exit
broke the pipe between git and grep, so git received a
SIGPIPE signal which killed it. Phillip suggested consuming the
whole output from Git if the exit code from it was wanted.
Matt replied to Phillip that he was interested in the exit code from
grep, not from git, and that Git shouldn’t output any error when
its output is connected to a pipe that gets broken, in the same way
as the yes command, for example, doesn’t output any error when
piped to grep -q y.
Junio Hamano, the Git maintainer, also replied to Phillip’s first message that the error Git emitted in such a case wasn’t useful to the user.
Matt replied to Junio that he thought no error at all should be emitted as most Unix tools don’t output any error.
Then Phillip replied to Matt’s first reply to him. He asked if all
Matt wanted was that git submodule status did not print any error
message when it receives a SIGPIPE signal. Matt replied that he
wanted both no error message and a 0 exit code from it.
Junio replied to Matt that it was reasonable to ask for no error
message, but it should be OK if the exit code was related to the
SIGPIPE message that the Git command received and that killed
it. Junio used the example that even yes exited with code 130 when
killed using the Control-C keys on a terminal.
The exit code associated with a signal is ‘128 + the signal number’,
for example as the Control-C keys send a SIGINT signal, whose signal
number is 2, processes killed this way should exit with code ‘128 + 2’,
so 130.
Eric Sunshine replied to Junio that it wasn’t clear how the exit code from Git was important in the discussion as in the original command line, Git appears before the pipe, so its exit code might be lost.
Matt replied to Eric that the exit code mattered if the pipefail
shell option was used.
Phillip replied to Matt suggesting he remap the exit code
associated with SIGPIPE, which is 141 (128 + 13), to 0, if he was
using pipefail but still wanted a 0 exit code. Phillip also gave
an example shell function to help with that remapping, and sent
a first version of a patch
to fix the error message.
Junio reviewed that patch and found that it was unnecessarily including the “signal.h” system header.
Phillip fixed that issue in version 2 of the patch which was merged and part of Git v2.47.0.
Editor’s note: Just like in our previous edition, we return with another GSoC retrospective interview in this issue. We hope the reflections shared by GSoC students will provide an insightful perspective that benefits the community. As always, we welcome your thoughts and feedback!
Who are you and what do you do?
Hey! I am Chandra Pratap (prefer going by Chand) and I am an undergraduate student of Mathematics at SVNIT, Surat, India. I have a passion for everything computing and like to solve leetcode-styled problems in my free time or contribute to open-source software.
How did you initially become interested in contributing to Git, and what motivated you to choose it as your GSoC project?
C was the first programming language that I learnt, and I wanted to try working on a non-trivial software project. I watched a YouTube video on open source and that’s where I got the idea of looking for open-source projects to contribute to. Git and VLC were the only open-source C-written software that I was familiar with and used in day-to-day life, so I decided to start contributing to Git out of the two. By the time GSoC came around, Git was the only open-source community that I was familiar with, so I decided to choose it as my GSoC organization.
How do you feel your contribution has impacted the Git community or the broader open-source ecosystem?
My project was about moving and improving reftable tests, so I think my contributions made life somewhat easier for other Git hackers, especially those who frequent the reftable sub-project. My project didn’t really affect any user-facing aspect of Git, so I don’t think it had a huge impact on the broader open-source ecosystem, besides the fact that it gained another lifelong contributor.
Is there any aspect of Git that you now see differently after having contributed to it?
Everything, to be honest. Working on and with Git for the duration of my project completely changed my mental model for the tool. Before GSoC, Git was a clunky tool reserved for software development work but post-Git, I know the most frequent commands like the back of my hand, and I’ve already used Git to version control many of my non-software files. I feel like I’ve learnt enough Git to last my entire career.
How do you balance your contributions with other responsibilities like work or school?
I had summer vacation for the entire duration of GSoC and no other work commitments, so I had no problems finding time for my GSoC project.
Can you share how GSoC helped enhance your technical and non-technical skills (like communication, project management, etc.)?
In terms of technical skills, I think my C and Git skills saw the biggest jump. I am a lot more comfortable working with those two tools than when I was pre-GSoC. Besides that, I’m a lot less scared of the command line now. In terms of non-technical skills, I believe I’ve gotten a lot better at composing mails and communicating with other professionals. I’ve learnt to write with the right amount of professionalism, so I don’t appear too uptight or too lax, the right way to respond to constructive feedback, how to time my schedule to fit with others’, especially those living in other parts of the globe, and how to ask good questions.
What was your biggest takeaway or learning from GSoC that you now apply regularly in your work?
I’d say the biggest takeaway from GSoC for me was that it is normal for everyone to face difficulties when trying to learn a new codebase, tool, etc, or even a different part of the same codebase. It is important to persevere and not be afraid of asking questions to achieve the desired results. Other than that, I’ve learnt a lot about good practices in software development, like appropriately splitting commits and writing good commit messages, that I subconsciously incorporate in my work now.
What was the biggest challenge you faced during your contributions to Git, and how did you overcome it?
The biggest challenge in contributing to Git was the initial phase of getting involved. I remember starting out working on a small patch for about 2 months with a lot of help from other contributors before it got accepted into Git’s upstream. After a few initial contributions, I grew more confident and could steadily find things to work on and produce acceptable results. The key to overcoming this challenge was to be persistent and patient, and not being afraid of asking silly questions.
Have you thought about mentoring new GSoC students?
I’m not sure about being a full-on mentor, but I’d love to co-mentor any future GSoC student(s) interested in working on the reftable project.
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?
The Git GUI tool. I believe that would make Git far more accessible than it currently is and get it incorporated in a lot more people’s day-to-day works.
If you could remove something from Git without worrying about backwards compatibility, what would it be?
The packed-refs format for refs seems redundant to me now that reftable is a core part of Git.
What is your favourite Git-related tool/library, outside of Git itself?
GitGitGadget was a lifesaver when I had just started contributing to Git, so that is probably my favourite Git related tool.
What is your toolbox for interacting with the mailing list and for development of Git?
I used Git’s send-email to send patches to the mailing list (especially
the --compose and --annotate flags) and Gmail’s online client to
convey non-patch mails. For developing Git, I used Vim as the editor
on an Ubuntu machine and Git as the version control software (duh).
How do you envision your own involvement with Git or other open-source projects in the future?
I plan on making small contributions to Git from time to time, since I cannot find enough time for larger patches. Other than that, I’ll try to volunteer as a Git mentor for future GSoC or Outreachy cohorts. Regarding other open-source projects, I’ll try contributing to them when I learn a new technology and want a real-world experience.
What is your advice for people who want to start Git development? Where and how should they start?
Go through Git’s ‘My First Contribution tutorial’ for the initial setup and to get an idea of what’s it like to work on Git. Then work on a few ‘microprojects’ (more information on the Git Developer’s website) to dip your toes in the Git Development community. From there, you can figure out interesting stuff to work on by yourself.
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?
Yes. I believe that Git is a tool that every working professional can find useful regardless of whether they work in the software industry or not, and working on Git through an open-source program is an excellent way to get good at it in a short period of time. There’s also the added benefit of joining a large and active community of amazingly experienced developers who can teach you a lot about writing software, and the software development workflow in general.
I think the key to getting selected as a participant in GSoC or other mentoring programs is getting involved as early as possible. The more time you allow yourself to get familiar with Git’s codebase and development workflow, the easier it becomes to find an apt project and write a reasonable proposal for it. Also, the initial phase of contributions is the most difficult part of getting involved with an open-source project, so it is better to allow yourself ample time to tackle that initial hurdle.
Various
%(is-base:) atom for git for-each-ref (see also the Brooke Kuhlmann article, mentioned below),
the new “Platform Support Policy” document,
git mergetool directly supporting Visual Studio Code merge tool, and others.init.defaultRefFormat configuration option that can be set to use reftable backend
(see Beginner’s guide to the Git reftable format),
init.defaultObjectFormat configuration option that can be set to sha256,
git refs verify, and others.Light reading
is-base field name recently added in
Git 2.47.0.git range-diff and interactive rebase can help with this task.How I Review GitHub PRs by Benjamin Pollack on bitquabit.
Scientific papers
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 Chandra Pratap, Brooke Kuhlmann, Štěpán Němec and Brandon Pugh.