tanga@tmjoris:~$ cat posts/first-post.md

From git config to git send-email

2026-11-05

I was introduced to Git while learning at ALX. My curious mind had lots of questions about why I was learning it, and I just wanted to understand more about it. The command I unironically loved the most back then was git config --global user.name "Tanga Joris". It was just so new and amazing.

The deeper I went down the rabbit hole, the more I realized that there is a community of people who make this awesome thing run smoothly: the contributors. I knew I wanted to become one one day, but I was such a novice. I also used to believe Git and GitHub were the same thing ¯\_(ツ)_/¯

With time I started roaming lore, the Git mailing list archive, and I found the dark-mode, plain-text discussions so cool. I really wanted to take part, but I was afraid I didn’t know enough yet. Then Outreachy came around. I applied this round and told myself that this year I am going to try all the things I have always feared, because I want to grow as a person and as an engineer. Yeap, that’s basically how I got here.

My first patch

My first patch was about using Q_() for messages with counts. Basically, it lets translators use the right plural form when a message talks about more than one thing, instead of being stuck with the singular. The process of sending a patch by email really surprised and amazed me. I didn’t expect it to be that way. I was actually really amazed to learn there is a command called git send-email. I was like “Daammnn!!!” I kinda expected a PR system where maintainers approve and everything gets merged.

With time I learnt how to submit my own patch from the guide. After sending the patch for my microproject, I was really happy to see Junio’s review. I had heard about Junio before, so imagine my shock when I opened Gmail and saw his review. I was over the moon. I then rewrote my commit message with his suggestions and resent my patch with git send-email (I still found it so cool the second time I did it, and also a bit scary).

The completion freeze

Once I was done with my microproject, I dug deeper for other work I could do, and found that some commands marked with the NO_PARSEOPT flag were never asked for their options by tab completion, even though they could answer. I was happy to have found something that is very user-facing. Later on I could easily show it to my tech friends if I managed to fix it.

Then I submitted my first patch, and René reviewed it and found that git fast-import --git-completion-helper waits for input, so tab completion would freeze once my patch landed. It showed me what code reviews have always taught me: you cannot catch everything. What you look at and deem perfect is hiding something that only a fresh set of eyes can see. I am really grateful for working on this patch because I learnt a lot more along the way.

I thought fixing the freeze might mean building on a series that Christian, one of our Outreachy mentors, was working on. I was afraid of introducing merge conflicts, or of changing something that had already been changed recently, so I asked him for permission. Junio responded in the best possible way: I don’t need Christian’s permission. Instead, I should make sure the work I build on is solid, and the best way to help with that is to review it. I learnt that the Git contribution culture is more proactive than I had assumed.

Then I sent my next version, where I fixed the freeze with a special case inside fast-import. Junio replied with one line I won’t forget: “It is way too ugly to target this so specifically.” Ouch :) But he also showed me a better way. There is a helper called show_usage_with_options_if_asked() that a lot of commands already call before they do any work, so he suggested putting the check there instead. That one small change fixed fast-import and every other command that calls it. So the lesson I took from it: if something has to be answered before a command starts working, fix it in the shared place, not in one command.

Reviews

More reviews came in with later versions of the patch. Kaartic, one of our mentors, pointed out that I had not answered a review and had jumped straight to the next version. He reminded me of the good practices in the MyFirstContribution guide, and I appreciated it a lot, because I had to put myself in the shoes of someone taking their time to review another person’s patch. The end goal is to make each other’s job as simple as possible.

I also learnt that a patch that fixes behaviour really needs tests that cover the fix. Cynthia, another applicant, showed me that my test only checked one of the two completion options, so if someone broke the other one, nobody would notice. Then when I tried her test, I found that it still passed even with my fix removed! So I added the same leftover-file check from my first test to it. Now I always ask myself: does this test fail without my fix? If it doesn’t, it’s not really testing anything.

What’s next

Right now I am working on making the completion helper work outside Git repositories, which also involves a patch fixing how git annotate answers the completion helper. I am also working on a fix for a crash in git apply. I also want to review other people’s patches to return the favour :) and finish writing my Outreachy proposal.