Re: [Outreachy][Proposal]: Reduce Git's global state to enable Git's libification

>
> Hi,
>
> On Thu, Oct 29, 2026 at 3:18 PM Okhuomon Ajayi
> <okhuomonajayi54@gmail.com> wrote:
> >
> > Hello,
> >
> > This is my proposal for the project "Reduce Git's global state to
> > enable Git's libification" for the December 2026 Outreachy internship.
>
> Thanks for your interest in Git.
>
> > Past Experience with Git
> > ========================
> >
> > I have been using Git since I started coding, for my own projects
> > and when collaborating with other developers.
> >
> > This is not my first time on the Git mailing list. I applied to
> > Outreachy in October 2025 and sent about ten patches in about a week
> > (patch-ids, commit.c comments, builtin/patch-id.c, gpg-interface)
> > [10]. 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, as Junio and Christian
> > pointed out [11].
> >
> > This year I slowed down. I read SubmittingPatches properly, wrote
> > my commit messages in the present tense, and sent one change at a
> > time. The hardest part was still sending new versions: keeping each
> > version in sync with the review, the right thread and the notes on
> > what changed since the last version. This time my microproject was
> > merged to master, and six more topics are in 'seen', some of
> > them marked "Will merge to 'next'?" in What's cooking.
>
> Nice.
>
> > Reviews and help to other applicants
> > ------------------------------------
> > + list-objects-filter-options: pass repository to partial clone
> >   helpers (Dorine Tipo)
> >   My reply: https://lore.kernel.org/git/CAFpMFfCu6JrUC8i453qBP=AktqcG_9sGX=1-1ekEDCYm_+pkUw@mail.gmail.com/
> >   Description: Dorine asked whether USE_THE_REPOSITORY_VARIABLE
> >   could be dropped. I applied the patch, removed the define and
> >   checked that the file still builds, so it can go in the same
> >   patch.
> >
> > + Microproject idea: modernize a file-existence check in
> >   t/t0081-find-pack.sh (Immaculate Mecha)
> >   My reply: https://lore.kernel.org/git/CAFpMFfA17dnuLSRt97BrM0u3cHAifJybr_Zc2ahr_zq2nspgsw@mail.gmail.com/
> >   Description: Pointed out that Shashank S had already changed that
> >   exact line, and suggested searching lore and "What's cooking"
> >   before choosing a microproject.
>
> Thanks for helping with reviews.
>
> [...]
>
> > This project reduces that global state step by step:
> > - removing the_repository from library code by passing the
> >   repository explicitly through the call chain, so files no longer
> >   need USE_THE_REPOSITORY_VARIABLE;
> > - moving repository-specific settings from environment.c into the
> >   repository, mostly struct repo_config_values and struct
> >   repo_settings;
> > - and, where a value is only used in one place, passing just that
> >   value down instead of the whole repository.
> >
> > A lot of progress has already been made: many settings that used
> > to be globals now live in struct repo_config_values, and many files
> > no longer need the_repository. But there is still plenty left.
> > Over a hundred library files outside builtin/ still define
> > USE_THE_REPOSITORY_VARIABLE, and environment.h still has globals
> > such as git_commit_encoding, git_log_output_encoding and
> > comment_line_str. That remaining library code is where I want to
> > focus.
>
> It's a good idea to focus on library code. You might also be
> interested in what Junio says about code in "builtin/" in:
>
> https://lore.kernel.org/git/xmqqmru76ybk.fsf_-_@gitster.g/
>
> [...]
>
> > Roadblocks seen in earlier work
> > -------------------------------
> > - Not every global belongs in struct repository. When Ayush
> >   Chandekar tried to move core.attributesfile into repo_settings,
> >   Junio questioned whether attribute data belongs to a repository at
> >   all, since attributes come from the index and the working tree,
> >   and compared it to how index_state is passed around instead of the
> >   repository [7]. The config value was later stored in struct
> >   repo_config_values instead [5].
> > - State used during early startup cannot simply be moved; the setup
> >   code has to change first. Patrick did this for
> >   is_bare_repository_cfg and git_work_tree_cfg in his "setup: drop
> >   global state" series [8]. have_git_dir() is still left, and
> >   environment.h says it "should not have to exist at all".
> > - builtin/ commands: the "repo" argument of cmd_foo() can be NULL
> >   (e.g. "git foo -h" outside a repository), so blindly replacing
> >   the_repository there causes crashes. Library code is the safer
> >   target.
>
> In the discussion I mentioned above, Junio says that the code in
> "builtin/" isn't reusable library code at all, and that it would be
> useful work to move that code into library helpers.
>
> [...]
>
> > Blogging
> > ========
> >
> > I will blog on Medium (https://medium.com/@okhuomonajayi54) and
> > post weekly updates on my progress, what I learned and the
> > challenges I faced. I will share each post on the mailing list,
> > like previous interns did.
>
> I wonder if blog posts on Medium are accessible to everyone.
>
> Thanks.