Reflections on My First Week as a Git Intern

This marks the end of my first week as an intern at Git. In my last blog post I listed a couple of tasks I planned to complete.

While trying to finish all the tasks, I accomplished several interesting things. These included reading Git’s documentation, going through Git’s codebase, meeting and asking questions (on WhatsApp) from my mentor, Christian, understanding the implementation details of my project, retrieving, testing, and reviewing my mentor’s initial patches for my project (“finishing the addition of an os-version capability to Git protocol v2”), and eventually working on my first patch series.

During this process, I learned new things and had some doubts, which I later resolved by consulting my mentor and, at times, digging further into Git’s codebase and documentation. Let’s go through all my completed tasks in detail and uncover some of the new and interesting things I learned.

Completed Tasks

1. Email to Git public mailing list

I sent an email to the Git public mailing list to finalize the implementation details of my project. This ensured that everyone involved in the project discussion was on the same page. Following my email, Randall, one of the participants in the discussion, wanted to know if the implementation details would be build-time or runtime. He also advised me to ensure that the feature works well on all machines, including non-Linux systems.

My project implementation will be runtime-based and include configuration options to disable the sending of OS information and provide more verbose options. This approach ensures that the code is portable and works across all systems. I will discuss these configuration options further in this blog post. You can find the public mailing list discussions here (which also includes my email).

Sending an email to the Git public mailing list is not as straightforward as it seems. The easiest way is to use git send-email through the command line. During my contribution stage, I used GitGitGadget for sending patches, so I hadn’t configured git send-email. Because of this, I had to set up my email server and configure git send-email. I learned how to do this by following Matheus’ git send-email tutorial.

2. Retrieving previous patches

I retrieved all the previous patches sent by my mentor and created a dedicated branch for them on my Git fork, which you can find here. As this was my first time retrieving patches from a Git public mailing list, I was initially confused about how to do it. Christian introduced me to b4, which simplifies this process, and I successfully integrated the patches into my Git codebase using git am. You can learn more about these tools in Hacking-Git.

3. Testing patches

After retrieving the patches, I set them up on both my local system and my GitHub repository. I ran the tests on my local system, which worked well since I am using Linux. To address and understand the failing tests on Windows, I used GitHub Actions with the provided YAML files. Initially, I couldn’t figure this out because GitHub Actions need to be enabled for forked repositories. Once I ran the tests (Github Actions), I identified the failing tests, which were caused by differences in the output of uname(1) and uname(2) on Windows. I will discuss this further in this blog.

4. Reviewing patches and implementations

I reviewed the retrieved patches and other code related to the implementation of Git protocol v2. My mentor’s patches, by default, sent all the OS information (i.e., uname -srvm) without configuration options to disable or minimize it. While reviewing the implementation, I discovered that both the Git server and Git client advertise their OS versions. The client would only advertise its OS version if the server supports and advertises this feature.

Around this time, I also explored the implementation of various Git configuration options, as I will be introducing new configuration options to either disable the sending of OS version information or make it more verbose.

5. Meeting with my mentor

On Friday, December 13th, I had a meeting with my mentor. We had several interesting discussions during this session.

I was able to clarify the implementation details about disabling this feature or making the OS version sent more verbose. By default, only the OS name will be sent, i.e., Windows, Linux, or macOS. There will be a configuration option, currently named transfer.advertiseOSVersion, which takes either true or false. This option will be used to opt out of the feature. False signifies that the user does not share their OS information, and true (the default) allows it to be sent.

There will also be another configuration option for making the output more verbose, e.g., uname -srvm, and another option to run a command for sending the details, as some Git configuration options provide this functionality. For now, I am focusing on implementing the first option.

6. Coding the first part of the project.

I have already started writing the code for implementing the first part of the project, i.e., sharing the default OS name and providing a configuration option to disable OS information sharing. You can find it here. Although this is not yet complete in any form, it should provide an overall idea of the implementation.

The major issue right now is deciding how to handle the differences between uname(1) and uname(2) on Windows. These differences make it challenging to test this feature on Windows.

-os-version=MINGW64_NT-10.0-20348.3.4.10-87d57229.x86_64.2024-02-14.20:17.UTC.x86_64 - expected +os-version=Windows.10.0.20348 - actual

The tests are being conducted using Bash scripting, and the code is written in C. On Windows, the uname(1) output from the command line differs from the uname(2) output from the C code. I have already contacted my mentor regarding this issue, and we will work together to determine the best approach. After resolving this, I will also complete writing tests for the default implementation and also the documentation.

Next Steps

1. Figure out how to handle the differences between uname(1) and uname(2) on Windows.

2. Complete writing tests for the implemented feature.

3. Add documentation for the new feature.

4. Send the patches to my mentor for review and address any concerns, corrections, or changes until my mentor approves.

5. Submit the patches to the Git public mailing list for review and address all community feedback until they are accepted.

Thank you! See you next week.