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 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 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.
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, 💐
]]>