Git Intern Week Two: Introducing the transfer.advertiseOSVersion config option.

It has already been two weeks since I started my Outreachy internship at Git. It has been a lot of learning and collaboration with my mentor. Last week, I mainly focused on writing code, improving it, and testing it based on my mentor's reviews.

If you remember, the first feature I was working on was ensuring that, by default, the Git v2 protocol should allow the sharing of the operating system (OS) name while providing a configuration option to disable it entirely. By now, I have completed the implementation, documentation, and testing of this feature. To accomplish this, I sent different iterations to my mentor on different branches. You can find all the branches in my Git fork here . Simply look for branches that start with "transfer."

I have not sent this feature yet to the Git public repository for public review and integration with Git, as my next task will involve making changes to different functions used in implementing this. It also needs a final review from my mentor.

Now, regarding the transfer.advertiseOSVersion config option

With my implementation, there is a new capability, os-version, in the Git v2 protocol, which allows the sharing of OS information. At this point, this capability only allows the sharing of the OS name (e.g., Linux) by default between the Git client (Git on your computer) and the server (GitHub). In other words, the server will send the os-version capability to the client, and the client will also share its own OS name with the server. It is possible that not everyone is comfortable sharing this information, which is why the transfer.advertiseOSVersion config option exists for disabling this capability. By default, the config option is set to true. To opt out of this capability, you can change the value of the config option to false (i.e., git config transfer.advertiseOSVersion false). The server checks this config option before sharing its OS name with the client. The client also checks if the server is sharing its OS info with the client and if the config option is true before sharing its own OS name with the server.

Now, regarding some blockers I encountered while implementing this feature

Let's discuss the issue I faced last week with the differences between uname(1) and uname(2) on Windows, which led to failing tests on Windows. My mentor suggested disabling the tests on Windows for now while we explore other approaches.

    if test_have_prereq WINDOWS
    then
        test_config transfer.advertiseOSVersion false
    else
        # Octal intervals \001-\040 and \177-\377
        # corresponds to decimal intervals 1-32 and 127-255
        printf "\nos-version=%s\n" $(uname -s | tr -d "\n" | tr "[\001-\040][\177-\377]" ".") >>agent_os_name
    fi

Above is basically how the code looks. In Git testing, there are some prerequisites set at the beginning of the testing. One of them is the environment in which the testing is being conducted. I used the test_have_prereq function to check if the environment is WINDOWS. If it is, the capability is disabled using the transfer.advertiseOSVersion option, which I introduced. I encountered some issues with tests that were using the output from the previous file. To resolve this, I applied the same approach of disabling the config option on WINDOWS in such test, ensuring uniformity in the environment between tests that depend on each other.

Next Steps

Since I have completed the first feature, my next task is to introduce the osversion.command to specialize the string sent to the other side using the new os-version capability. This will use the output of the command specified by this config option. Essentially, instead of just the OS name, the client and server will share a string that represents a command like uname -rvm, and the output will be the value for the os-version capability.

Thank you, and see you in the next blog post!