The Last Contribution: Git

After contributing to a few free software projects, we finally dove into the one I was most excited about: Git.

Since our contribution to GNOME was rejected, we had the option to keep looking for other issues in that project or to choose a different one. We decided to go with Git because I’ve always admired the project, given how essential it is for all computer scientists. Moreover, Git involves interesting applications beyond software engineering, touching areas like algorithms and data structures. Contributing to it can also be helpful when applying for programs like GSoC and Outreachy.

Choosing the Contribution

To get started, I reached out to Lucas Oshiro to express our interest in contributing and to ask for some guidance. He pointed us to the GSoC Microprojects page at https://git.github.io/SoC-2025-Microprojects/, where we could browse through several options.

After cloning the repository and reviewing the list of tasks—checking which ones were still available (i.e., not already completed)—we found a test file that still had a valid issue to work on.

The t2400 test file includes several test cases that use the Bash command test -[e|f|d] to check whether executables, files, or directories exist.

Although this method still works, it’s now considered outdated. The microproject’s goal is to replace these calls—not because they’re broken, but because Git provides built-in helper functions like test_path_is_missing, test_path_is_dir, and test_path_is_file. These built-ins perform the same checks but include more helpful diagnostic messages when something fails, making the test suite clearer and more maintainable.

An example of the change we made:

-       test -f .git/worktrees/here-with-lock-reason/locked &&
+       test_path_is_file .git/worktrees/here-with-lock-reason/locked &&

Understanding the “Git Way”

A big part of the work involved learning how Git handles patch submissions. As Lucas Oshiro once told us, there are very specific conventions about writing and structuring commits. For instance, commit messages should be limited to 72 characters per line. That’s very true—Git even admits in their SubmittingPatches guide that they are picky about it!

That being said, the first version (v1) of our patch received feedback the same day we sent it. The maintainers suggested some improvements, especially regarding how test commands were used with test files:

They also requested a few changes to our commit style:

After incorporating those suggestions and going through a few more iterations, we submitted version 4 (v4). Just a day later, we received confirmation: it had been accepted! Yay!

Conclusions

Even though this contribution wasn’t particularly complex, we learned a great deal from it. We spent a lot of time researching how the community operates, their patch submission patterns, and Git’s internal practices. It was also really nice to interact with some of the maintainers—we were genuinely surprised by how quickly they responded and how welcoming and patient they were in explaining what needed to be improved before the patch could be accepted.

This experience definitely made me more excited to continue contributing to Git and has encouraged me to seriously consider applying for GSoC to work on Git more professionally.