This post is about what I worked on during the contribution period, what went wrong, and what the reviewers taught me.

What the project is about

A lot of Git's code uses a global variable called the_repository. It points to the repository Git is running in. That works when Git runs as a command, but it is a problem if you want to use Git's code as a library, for example to work with two repositories in the same program. A function that quietly reaches for the_repository can end up using the wrong one.

The fix is simple to describe: when a function already gets a struct repository *, it should use that, and when it doesn't, the caller should pass one down. Once a file no longer uses the global, it can drop the USE_THE_REPOSITORY_VARIABLE macro at the top.

Simple to describe, but not always simple to do, as I found out.

My first try in 2025

This is not my first time on the Git mailing list. I applied in October 2025 and sent about ten patches in one week. None of them were merged. I was sending too fast, my subject lines had doubled prefixes like "[PATCH] [PATCH v2]", and my commit messages did not follow the project style. Christian Couder and Junio C Hamano pointed this out, kindly but clearly.

Honestly, I was overwhelmed. I felt really bad and a bit intimidated, because I kept making mistakes and I wasn't getting it right. I admit I stepped away. I even unsubscribed from the mailing list, because I kept seeing all the updates and I couldn't contribute.

This year I came back and slowed down. I read SubmittingPatches properly, wrote commit messages that explain why and not only what, and sent one change at a time.

What I contributed

My microproject (merged). A progress message in delta-islands.c used _(), so "Marked 1 islands" could not be translated properly in languages with several plural forms. I changed it to Q_(), which picks the right form from the count. Junio asked me to move a note below the --- line, I sent v2, and it was merged. It is listed in the Git v2.98.0 release notes. https://lore.kernel.org/git/20261013164922.93099-1-okhuomonajayi54@gmail.com/

diffcore-break and diffcore-rename (merged to master). diffcore-rename.c already had the repository through its diff options, but still used the global for the hash algorithm and the progress meter. I used the repository from the options and removed the macro. Patrick Steinhardt called it "trivially correct". https://lore.kernel.org/git/20261024221341.92086-1-okhuomonajayi54@gmail.com/

range-diff and bundle-uri (in 'next'). Both followed the same idea. On bundle-uri, a reviewer pointed out that only two uses of the global were left in the file, so in v2 I finished the job and dropped the macro.

A few more patches are still in review.

The notes story

This is the part I learned the most from.

notes-utils.c has functions that take a repository but still read and update the notes ref in the_repository. My first patch fixed that, but kept the macro. Patrick asked why I stopped one step short, so I sent v2, which removed the macro.

Then Junio pointed out something I had missed: the functions in notes.c that notes-utils.c calls still only work with the_repository. Removing the macro from notes-utils.c would make it look finished when it wasn't. He suggested hiding the header behind the macro instead, and I sent that.

Then Patrick asked a fair question: why not fix notes.c itself? Junio agreed that would be the ideal way.

So I did that. I sent one series of 6 patches. struct notes_tree now remembers which repository it was loaded from, and notes.c uses that when it reads, writes and prunes notes. With that in place, notes-utils.c really can drop the macro. Here is the idea in one line:

-	refs_update_ref(get_main_ref_store(the_repository), buf.buf,
+	refs_update_ref(get_main_ref_store(r), buf.buf,

This is the cover letter of the series on the mailing list archive:

https://lore.kernel.org/git/20261105203344.48513-1-okhuomonajayi54@gmail.com/

What the reviewers taught me

The biggest lesson from the notes story is to follow the calls down. Before I say a file no longer depends on the_repository, I now check what the functions it calls actually do.

The second one came from commit_encoding. I moved a global into a config struct, and Junio pointed out that only one file uses it, so it is better to pass the value down. I should have looked at earlier discussions and compared designs before writing any code.

Patrick also asked me to send fewer, bigger series instead of many small topics, because that is easier for reviewers. And along the way I picked up the mailing-list habits: plain text, no top-posting, short quotes, and notes for reviewers below the --- line.

Helping others

I reviewed some patches from other applicants, and I helped proofread edition 140 of Git Rev News, the community newsletter. I fixed typos and grammar in the Developer Spotlight interview, and I am credited at the end of the edition:

https://github.com/git/git.github.io/pull/878

What's next

For now I'm waiting for reviews on the notes series. After that, I want to keep working bottom-up through Git's library code: group related files into one series, pass values down instead of adding new globals, and talk about the design on the list before writing code for the harder cases.

Thanks to my mentors Christian Couder, Usman Akinyemi, Siddharth Asthana and Kaartic Sivaraam, and to Junio C Hamano, Patrick Steinhardt, Karthik Nayak and Pablo Sabater for reviewing my patches and helping me improve them.