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

>
> Hello,
>
> This is my proposal for the project "Reduce Git's global state to
> enable Git's libification" for the December 2026 Outreachy internship.

> 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.

> 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.

> 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.

> 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.

> 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.