Hi, I’m Cynthia Uche. I’m also called Priestess. I’m a software engineer from Nigeria, and I’m applying to Outreachy with the Git project for the December 2026 round. If I’m selected, this is where I will write every week about what I’m learning.

A bit about me

C was the first language I learned, so I’m comfortable reading and writing it, even though I hadn’t used it much day to day until I started reading Git’s source. I also have a merged patch in OpenStack Manila, which went through Gerrit review, so reworking a change after review comments is not new to me. Git’s mailing-list workflow is still a different world, and I’m enjoying learning it.

My first Git patch

My microproject was t2104: avoid suppressing git's exit code. The idea is small: in a test script, a pipe like git ... | grep ... hides git’s exit code, so if git crashes, the test can still pass. The fix is to write git’s output to a file first, then inspect the file. It was merged to master after review.

Using git send-email seemed challenging at first, and GitGitGadget looked like a far easier option. But I was really curious about how send-email worked, so I learned it, and now I actually enjoy using it.

The project I want to work on

The project is “Improve how command arguments and options are scanned and parsed”. Some commands need to look at a few options before they call parse_options(). fast-import is the example. It has to know about --allow-unsafe-features before it reads the “feature” lines in the stream.

The old early scan was a hand-written loop, and it can disagree with parse_options(). That one accepts abbreviations, so something the scan sees as a flag can really be the value of another option. For a safety check, that is a real problem.

There is a series in progress that adds early_scan_options(), which reads the same option table as parse_options() so the two agree. I reviewed one of its patches, ran the related tests, and noticed that one argument passed at a call site didn’t match how the real parse is configured. Reading reviews from experienced contributors on the same series was an education in itself.

What I plan to write here

  • What I learn each week, including my mistakes
  • How I read and reproduce a bug before changing code
  • Notes on review feedback and how I respond to it
  • Things I wish I knew when I started

I love sharing what I learn, and I trust I’ll learn a lot. If you are also new to Git, do say hello.

Till next time, 💐