{"thread":{"id":"66705","subject":"[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","startedAt":"2026-10-29T14:18:18Z","lastAt":"2026-11-05T00:16:08Z","messageCount":5,"participants":["Okhuomon Ajayi","Christian Couder","Usman Akinyemi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"556789","messageId":"20261029141818.40193-1-okhuomonajayi54@gmail.com","threadId":"66705","inReplyTo":null,"subject":"[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","fromName":"Okhuomon Ajayi","fromEmail":"okhuomonajayi54@gmail.com","sentAt":"2026-10-29T14:18:18Z","receivedAt":"2026-10-29T14:18:18Z","isPatch":false,"sender":{"key":"okhuomonajayi54@gmail.com","avatar":null},"body":"Hello,\n\nThis is my proposal for the project \"Reduce Git's global state to\nenable Git's libification\" for the December 2026 Outreachy internship.\n\nI'd appreciate any feedback.\n\nPersonal Information\n====================\n\nFull Name: Okhuomon Rosemary Ajayi\nEmail: okhuomonajayi54@gmail.com\nGitHub: https://github.com/six-shot\nBlog: https://medium.com/@okhuomonajayi54\nLocation: Lagos, Nigeria (WAT, UTC+1)\n\nAbout Me\n========\n\nI am Okhuomon Rosemary Ajayi, often known as \"sixshot\", a\nself-taught software developer from Lagos, Nigeria. I am obsessed\nwith robots and intelligent mechanical systems. C was the first\nprogramming language I picked up, before I moved into frontend and\nmobile development. Working on Git during this contribution period\nhas brought me back to C, and I have enjoyed working at that lower\nlevel again.\n\nBefore Git, I contributed to other open source projects. In Servo\nI fixed clippy warnings in the script crate and improved some\ndocumentation [12]. In the OCaml ecosystem I added Deflate support\nand horizontal differencing to ocaml-tiff, and worked on raven and\nYOCaml [13]. In LibreOffice I worked in the C++ core, fixing a bug\nwhere Infobar keys reached the document and cleaning up unit\nconversion code [14]. In Mozilla Firefox I fixed layout bugs in\nvertical tabs and split view [15].\n\nAs a woman in tech, I know how much it helps to see someone like\nyourself doing the work. That is why I volunteered to train girls at\nEdunity for Girls, helping them get started in tech.\n\nHonestly, I would like to be part of the Git community and keep on\ncontributing to open source. This project lets me do that in C, the\nlanguage I started with, and my patches on the_repository so far\nhave shown me how much there is to learn here.\n\nPast Experience with Git\n========================\n\nI have been using Git since I started coding, for my own projects\nand when collaborating with other developers.\n\nThis is not my first time on the Git mailing list. I applied to\nOutreachy in October 2025 and sent about ten patches in about a week\n(patch-ids, commit.c comments, builtin/patch-id.c, gpg-interface)\n[10]. None of them were merged. I was sending too fast, my subject\nlines had doubled prefixes like \"[PATCH] [PATCH v2]\", and my commit\nmessages did not follow the project style, as Junio and Christian\npointed out [11].\n\nThis year I slowed down. I read SubmittingPatches properly, wrote\nmy commit messages in the present tense, and sent one change at a\ntime. The hardest part was still sending new versions: keeping each\nversion in sync with the review, the right thread and the notes on\nwhat changed since the last version. This time my microproject was\nmerged to master, and six more topics are in 'seen', some of\nthem marked \"Will merge to 'next'?\" in What's cooking.\n\nContributions to the Git Community\n==================================\n\nMicroproject\n------------\n+ delta-islands: use Q_() for island count\n Thread: https://lore.kernel.org/git/20261013203042.58610-1-okhuomonajayi54@gmail.com/\n Branch: oa/delta-islands-i18n-use-q\n Status: merged to 'master'\n Commit: 60e16b0387 (merge commit 7ac84b7267), listed in the\n Git 2.98.0 release notes\n Description: The island count in a progress message was built with\n a plain _() so translators could not handle plural forms. Use Q_()\n instead. v2 moved a reviewer note below the --- line after\n Junio's review.\n\nPatches related to the project (the_repository)\n------------------------------------------------\n+ merge: stop using the_repository\n Thread: https://lore.kernel.org/git/20261015142532.48175-1-okhuomonajayi54@gmail.com/\n Branch: oa/merge-without-the-repository\n Status: in 'seen'\n Description: Pass the repository already available at the entry\n points down to the helpers, removing the_repository and\n the_hash_algo from merge.c.\n\n+ merge-blobs: stop using the_repository\n Thread: https://lore.kernel.org/git/20261017105244.90295-1-okhuomonajayi54@gmail.com/\n Branch: oa/merge-blobs-stop-using-the-repository\n Status: in 'seen'\n Description: Use the repository reachable from the index_state\n instead of the global.\n Usman suggested renaming \"r\" to \"repo\"; Junio preferred the short\n \"r\" used elsewhere for \"struct repository *\", so I kept it [9].\n\n+ diffcore-break: remove USE_THE_REPOSITORY_VARIABLE\n Thread: https://lore.kernel.org/git/20261014114904.85300-1-okhuomonajayi54@gmail.com/\n Status: in 'seen', marked \"Will merge to 'next'?\"\n Description: An earlier commit removed the last use of\n the_repository in diffcore-break.c, so the file no longer needs\n USE_THE_REPOSITORY_VARIABLE. Drop the define.\n\n+ checkout: make unique_tracking_name() use the given repository\n (2 patches)\n Thread (v3): https://lore.kernel.org/git/20261023211533.73433-1-okhuomonajayi54@gmail.com/\n Status: v3 in 'seen'\n Description: Pass the repository to unique_tracking_name() and\n carry it in struct tracking_name_data, so checkout.c no longer\n needs USE_THE_REPOSITORY_VARIABLE. Usman asked for a clearer\n commit message in v1. In v2 Junio pointed out that the function\n still walked the remotes with for_each_remote(), which only works\n on the_repository, so v3 adds repo_for_each_remote() first.\n\n+ diffcore-rename: stop using the_repository\n Thread: https://lore.kernel.org/git/20261024221341.92086-1-okhuomonajayi54@gmail.com/\n Status: in 'seen', marked \"Will merge to 'next'?\"\n Description: diffcore_rename_extended() already has the\n repository through its options. Use its hash algorithm when\n checking for empty blobs, pass it to start_delayed_progress(),\n and drop USE_THE_REPOSITORY_VARIABLE. Patrick reviewed it and\n said it looks correct.\n\n+ notes-cache: read the cache ref from the given repository\n Thread: https://lore.kernel.org/git/20261026102603.32377-1-okhuomonajayi54@gmail.com/\n Status: reviewed by Junio, waiting to be queued\n Description: notes_cache_match_validity() already receives the\n repository but read the ref from the_repository. Pass it to\n get_main_ref_store() so the check reads the same repository.\n\n+ combine-diff: use the repository from diff options\n Thread: https://lore.kernel.org/git/20261026111303.92117-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: show_combined_header() and show_patch_diff()\n already have opt->repo; use it for the hash algorithm,\n abbreviation and gitlinks. The file still needs the macro for\n DEFAULT_ABBREV, which depends on the default_abbrev global.\n\n+ negotiator/default: stop using the_repository\n Thread: https://lore.kernel.org/git/20261027153429.14131-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: Give default_negotiator_init() a repository,\n store it on the negotiation state and use it to parse commits,\n clear marks and walk refs. Drop USE_THE_REPOSITORY_VARIABLE.\n\n+ bundle-uri: stop using the_repository\n Thread (v2): https://lore.kernel.org/git/20261029131325.79176-1-okhuomonajayi54@gmail.com/\n Status: v1 in 'seen' and marked ready for 'next'; v2 sent to\n replace it, and Patrick confirmed the v2 diff\n Description: unbundle_from_file() unbundles objects into the\n given repository but read and wrote refs in the_repository, and\n fetch_bundle_uri() used the_repository for tracing. v1 used the\n given repository for both and was reviewed by Karthik. Patrick\n then pointed out that only two more uses were left in the file,\n in find_temp_filename() and copy_uri_to_file(), so v2 passes the\n repository to them too and drops USE_THE_REPOSITORY_VARIABLE\n from bundle-uri.c.\n\n+ range-diff: use diffopt->repo instead of the_repository\n Thread (v2): https://lore.kernel.org/git/20261029084720.93221-1-okhuomonajayi54@gmail.com/\n Status: v2 sent, waiting for review\n Description: output_pair_header() and patch_diff() receive a\n diffopt that names the repository, but still used the_repository\n and the_hash_algo. Use diffopt->repo, and give get_filespec() a\n hash algorithm parameter. v2 rewords the commit message after\n Pablo's review.\n\n+ environment: move commit_encoding into repo_config_values\n Thread: https://lore.kernel.org/git/20261021155608.58509-1-okhuomonajayi54@gmail.com/\n Status: v1 reviewed by Junio; v2 in progress\n Description: v1 moved the global into struct repo_config_values.\n Junio pointed out that only commit.c uses it and suggested passing\n a \"const char *\" encoding down to the functions instead of the\n whole repository. v2 will do that.\n\nOther patches\n-------------\n+ credential-store: add lockTimeout config option (#leftoverbits)\n Thread (v2): https://lore.kernel.org/git/20261016212216.58000-1-okhuomonajayi54@gmail.com/\n Status: v2 sent after Junio's review, waiting\n Description: Junio noted in the rerere thread that\n credentialStore.lockTimeoutMS is the only timeout setting with\n the unit in its name, and suggested a synonym without \"MS\". Add\n credentialStore.lockTimeout; the old name keeps working.\n\nReviews and help to other applicants\n------------------------------------\n+ list-objects-filter-options: pass repository to partial clone\n helpers (Dorine Tipo)\n My reply: https://lore.kernel.org/git/CAFpMFfCu6JrUC8i453qBP=AktqcG_9sGX=1-1ekEDCYm_+pkUw@mail.gmail.com/\n Description: Dorine asked whether USE_THE_REPOSITORY_VARIABLE\n could be dropped. I applied the patch, removed the define and\n checked that the file still builds, so it can go in the same\n patch.\n\n+ Microproject idea: modernize a file-existence check in\n t/t0081-find-pack.sh (Immaculate Mecha)\n My reply: https://lore.kernel.org/git/CAFpMFfA17dnuLSRt97BrM0u3cHAifJybr_Zc2ahr_zq2nspgsw@mail.gmail.com/\n Description: Pointed out that Shashank S had already changed that\n exact line, and suggested searching lore and \"What's cooking\"\n before choosing a microproject.\n\nLearning resource\n-----------------\n+ \"Learn C by reading Git\" -- a zero-to-hero guide\n Link: https://six-shot.github.io/six-shot-git-c-zero-to-hero/\n Description: C was the first language I learned, but I had not\n used it in a while. I built this guide during this Outreachy\n contribution period so I could understand C well by learning it\n with Git itself. It teaches C from zero using real code from\n git.git (repository.h, merge-blobs.c, git.c, ...), with\n exercises. It covers the patterns this project depends on:\n structs and pointers, passing \"struct repository *\" down a call\n chain, and why global variables like the_repository are a\n problem. I hope it also helps other people who want to start\n contributing to Git.\n\nProject Overview\n================\n\nGit keeps the state of the repository it is working on in a single\nglobal object, the_repository, which is a \"struct repository\". A\nlot of internal code uses this global directly instead of taking a\nrepository as a parameter. On top of that, many configuration and\nenvironment values are stored as global variables in environment.c\nrather than in the repository they belong to.\n\nThis design assumes that a process only ever works with one\nrepository. That is not true for things like submodules, and it is\none of the main things blocking the long-term goal of libifying Git,\nwhere a program could open several repositories at the same time.\nWith shared globals, two repositories in one process would read and\noverwrite the same values, which can lead to wrong behaviour that is\nhard to debug. It also makes the code harder to read and test,\nbecause a function's dependencies are hidden instead of being\nvisible in its parameters.\n\nThis project reduces that global state step by step:\n- removing the_repository from library code by passing the\n repository explicitly through the call chain, so files no longer\n need USE_THE_REPOSITORY_VARIABLE;\n- moving repository-specific settings from environment.c into the\n repository, mostly struct repo_config_values and struct\n repo_settings;\n- and, where a value is only used in one place, passing just that\n value down instead of the whole repository.\n\nA lot of progress has already been made: many settings that used\nto be globals now live in struct repo_config_values, and many files\nno longer need the_repository. But there is still plenty left.\nOver a hundred library files outside builtin/ still define\nUSE_THE_REPOSITORY_VARIABLE, and environment.h still has globals\nsuch as git_commit_encoding, git_log_output_encoding and\ncomment_line_str. That remaining library code is where I want to\nfocus.\n\nReview of Previous Work and Strategies\n======================================\n\nFrom reading past series on the list and from my own patches, I see\nthree strategies, and the right one depends on the variable:\n\n1. Thread the repository through the call chain, bottom-up.\n Patrick Steinhardt introduced USE_THE_REPOSITORY_VARIABLE so files\n that still depend on the global are marked [1]. Work then goes from\n the lowest layers up, removing the macro file by file (objects [2],\n path [3], packfile by Karthik [4]). My patches to merge.c,\n merge-blobs.c, diffcore-break.c, diffcore-rename.c, checkout.c,\n notes-cache.c, combine-diff.c, negotiator/default.c,\n bundle-uri.c and range-diff.c follow this pattern.\n\n2. Move repository-scoped config into the repository.\n core.hooksPath and core.sharedRepository moved into repo-settings\n with accessors [3]. Later, Olamide Caleb Bello's Outreachy series\n added struct repo_config_values, with repo_config_values(repo) as\n the accessor, and moved core.attributesFile, core.sparseCheckout\n and branch.autoSetupMerge into it [5]. Others, such as Tian Yuchen,\n have moved more values there since.\n\n3. Pass only the value the function needs.\n the_hash_algo was replaced by an explicit\n \"const struct git_hash_algo *\" in csum-file.c [2]. Junio asked for\n the same thing on my commit_encoding patch: since only commit.c\n uses the variable, pass the encoding string instead of adding it\n to repository config [6].\n\nRoadblocks seen in earlier work\n-------------------------------\n- Not every global belongs in struct repository. When Ayush\n Chandekar tried to move core.attributesfile into repo_settings,\n Junio questioned whether attribute data belongs to a repository at\n all, since attributes come from the index and the working tree,\n and compared it to how index_state is passed around instead of the\n repository [7]. The config value was later stored in struct\n repo_config_values instead [5].\n- State used during early startup cannot simply be moved; the setup\n code has to change first. Patrick did this for\n is_bare_repository_cfg and git_work_tree_cfg in his \"setup: drop\n global state\" series [8]. have_git_dir() is still left, and\n environment.h says it \"should not have to exist at all\".\n- builtin/ commands: the \"repo\" argument of cmd_foo() can be NULL\n (e.g. \"git foo -h\" outside a repository), so blindly replacing\n the_repository there causes crashes. Library code is the safer\n target.\n- Naming: Junio prefers a short \"r\" for \"struct repository *\"\n parameters [9].\n\nCan there be clear criteria? Only partly. My working checklist:\n a. Who reads and writes it? (git grep every use)\n b. Is it per-repository, per-index, per-subsystem or process-wide?\n c. Is it needed before a repository is set up?\n d. Does only one file use it? Then pass the value (strategy 3).\n e. Search the list for earlier attempts and objections first.\nAnything still unclear goes to the list as a question before code.\n\nExample: git_log_output_encoding\n--------------------------------\nThis is the encoding Git uses when it shows commit messages. It is\nthe twin of git_commit_encoding, which my commit_encoding patch\nworks on, but it is harder:\n\n- It is set in two places: from i18n.logOutputEncoding in\n environment.c, and from \"git log --encoding=...\" in revision.c.\n Other revision options like --reverse are stored in struct\n rev_info, but --encoding writes the global. The parsing was moved\n into revision.c in 2006 (7cbcf4d557) so that rev-list and\n diff-tree could use it too, and at that time the rest of the\n code read the encoding from a global anyway.\n\n- It is read through get_log_output_encoding() 15 times in 12\n files. Many of these callers (log-tree.c, bundle.c, submodule.c,\n sequencer.c) copy it into\n \"struct pretty_print_context.output_encoding\", so that struct\n already carries the value. That points to strategy 3: fill the\n context once from the caller and let the pretty-printing code use\n ctx->output_encoding instead of calling the global getter.\n\n- Some callers do not print a log: remote-curl.c uses it to\n re-encode an error message from the server, and sequencer.c uses\n it when building the todo list. So the value is really \"the\n user's display encoding\", not something that belongs to one\n repository. That is a reason NOT to put it in\n repo_config_values, which is also what Junio said about\n commit_encoding [6].\n\nMy plan for it: first do commit_encoding (single caller), then\npropose on the list storing the --encoding value in struct rev_info\nand passing it through pretty_print_context, and ask whether that\ndesign is acceptable before writing the series.\n\nInternship Plan and Timeline\n============================\n\nThe internship runs from 7 December 2026 to 8 March 2027.\n\nBefore the internship (now -- 6 Dec 2026)\n- Finish open patches: commit_encoding v2, combine-diff,\n negotiator/default, range-diff, notes-cache and credential-store.\n- Keep reviewing other applicants' patches in the global-state area.\n- Build a list of remaining globals and USE_THE_REPOSITORY_VARIABLE\n files outside builtin/, ordered by how low in the call graph they\n sit.\n\nWeeks 1-2 (7 Dec -- 20 Dec)\n- Agree the list and order with mentors.\n- First small series: one library file off\n USE_THE_REPOSITORY_VARIABLE.\n- First blog post.\n\nWeeks 3-6 (21 Dec -- 17 Jan)\n- environment.c globals that only one subsystem uses: pass the value\n down, as Junio suggested for commit_encoding.\n- git_log_output_encoding next: it is read in 12 files and also set\n by \"--encoding\", so agree the design on the list before coding.\n- Ask on the list before touching the comment_line_str group and the\n abbrev globals, since they are read in many places.\n\nWeeks 7-10 (18 Jan -- 14 Feb)\n- Continue bottom-up removal of the_repository in library code,\n one subsystem per series.\n- Look at a harder item if mentors agree, such as have_git_dir(),\n which still depends on the_repository.\n\nWeeks 11-13 (15 Feb -- 8 Mar 2027)\n- Land rerolls, no new big series.\n- Final report on the blog and the list.\n- Update the \"Learn C by reading Git\" guide with what I learned.\n\nThroughout: small series, reply to reviews within a day or two,\nweekly blog post, weekly sync with mentors.\n\nAvailability\n============\n\nI can give 40 hours a week to the project during the internship.\nI am based in Lagos (WAT, UTC+1) and can adjust my hours for calls\nand reviews when needed.\n\nBlogging\n========\n\nI will blog on Medium (https://medium.com/@okhuomonajayi54) and\npost weekly updates on my progress, what I learned and the\nchallenges I faced. I will share each post on the mailing list,\nlike previous interns did.\n\nAfter the Internship\n====================\n\nAfter the internship I want to continue as an open source\ncontributor to Git: sending patches, reviewing others' work and\nhelping new contributors get started, the way Usman and Junio\nhelped me. I also want to keep the \"Learn C by reading Git\" guide\nup to date so it stays useful for future applicants.\n\nAppreciation\n============\n\nI want to thank Usman and Junio for always helping out during this\ncontribution period. I also want to thank Patrick, Karthik, Pablo,\nChristian, Siddharth and Kaartic, and everyone in the Git community\nfor being so welcoming.\n\nReferences\n==========\n[1] https://lore.kernel.org/git/cover.1718347699.git.ps@pks.im/\n[2] https://lore.kernel.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/\n[3] https://lore.kernel.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/\n[4] https://lore.kernel.org/git/cover.1733236936.git.karthik.188@gmail.com/\n[5] https://lore.kernel.org/git/cover.1771258573.git.belkid98@gmail.com/\n[6] https://lore.kernel.org/git/xmqq33tyn5qi.fsf@gitster.g/\n[7] https://lore.kernel.org/git/xmqqwmcw97z2.fsf@gitster.g/\n[8] https://lore.kernel.org/git/20260611-b4-pks-setup-drop-global-state-v2-0-a6f7269c841d@pks.im/\n[9] https://lore.kernel.org/git/xmqqwlrcrqaz.fsf@gitster.g/\n[10] https://lore.kernel.org/git/20251009214445.1190274-1-okhuomonajayi54@gmail.com/\n[11] https://lore.kernel.org/git/CAP8UFD2sdvkv_ZqiLZU9k5zF+tM3UTQ8+mJjziRZGzOra6dMFA@mail.gmail.com/\n https://lore.kernel.org/git/xmqqo6q5z6iu.fsf@gitster.g/\n[12] https://github.com/servo/servo/pulls?q=is%3Apr+author%3Asix-shot+is%3Amerged\n[13] https://github.com/geocaml/ocaml-tiff/pull/80\n https://github.com/raven-ml/raven/pulls?q=is%3Apr+author%3Asix-shot\n https://github.com/xhtmlboi/yocaml/pulls?q=is%3Apr+author%3Asix-shot\n[14] https://gerrit.libreoffice.org/q/owner:okhuomonajayi54@gmail.com+status:merged\n https://whatsnew.libreoffice.org/25.8.4/\n[15] https://github.com/mozilla-firefox/firefox/commits?author=okhuomonajayi54@gmail.com\n\nThanks for reading.\n\nOkhuomon Ajayi\n\n"},{"id":"557318","messageId":"CAP8UFD1VUCTeXNbb4YKGkZRWY8i56Zms_=qkR2oqF7e1Aagy1Q@mail.gmail.com","threadId":"66705","inReplyTo":"20261029141818.40193-1-okhuomonajayi54@gmail.com","subject":"Re: [Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-11-03T13:46:39Z","receivedAt":"2026-11-03T13:46:39Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Thu, Oct 29, 2026 at 3:18 PM Okhuomon Ajayi\n wrote:\n>\n> Hello,\n>\n> This is my proposal for the project \"Reduce Git's global state to\n> enable Git's libification\" for the December 2026 Outreachy internship.\n\nThanks for your interest in Git.\n\n> Past Experience with Git\n> ========================\n>\n> I have been using Git since I started coding, for my own projects\n> and when collaborating with other developers.\n>\n> This is not my first time on the Git mailing list. I applied to\n> Outreachy in October 2025 and sent about ten patches in about a week\n> (patch-ids, commit.c comments, builtin/patch-id.c, gpg-interface)\n> [10]. None of them were merged. I was sending too fast, my subject\n> lines had doubled prefixes like \"[PATCH] [PATCH v2]\", and my commit\n> messages did not follow the project style, as Junio and Christian\n> pointed out [11].\n>\n> This year I slowed down. I read SubmittingPatches properly, wrote\n> my commit messages in the present tense, and sent one change at a\n> time. The hardest part was still sending new versions: keeping each\n> version in sync with the review, the right thread and the notes on\n> what changed since the last version. This time my microproject was\n> merged to master, and six more topics are in 'seen', some of\n> them marked \"Will merge to 'next'?\" in What's cooking.\n\nNice.\n\n> Reviews and help to other applicants\n> ------------------------------------\n> + list-objects-filter-options: pass repository to partial clone\n> helpers (Dorine Tipo)\n> My reply: https://lore.kernel.org/git/CAFpMFfCu6JrUC8i453qBP=AktqcG_9sGX=1-1ekEDCYm_+pkUw@mail.gmail.com/\n> Description: Dorine asked whether USE_THE_REPOSITORY_VARIABLE\n> could be dropped. I applied the patch, removed the define and\n> checked that the file still builds, so it can go in the same\n> patch.\n>\n> + Microproject idea: modernize a file-existence check in\n> t/t0081-find-pack.sh (Immaculate Mecha)\n> My reply: https://lore.kernel.org/git/CAFpMFfA17dnuLSRt97BrM0u3cHAifJybr_Zc2ahr_zq2nspgsw@mail.gmail.com/\n> Description: Pointed out that Shashank S had already changed that\n> exact line, and suggested searching lore and \"What's cooking\"\n> before choosing a microproject.\n\nThanks for helping with reviews.\n\n[...]\n\n> This project reduces that global state step by step:\n> - removing the_repository from library code by passing the\n> repository explicitly through the call chain, so files no longer\n> need USE_THE_REPOSITORY_VARIABLE;\n> - moving repository-specific settings from environment.c into the\n> repository, mostly struct repo_config_values and struct\n> repo_settings;\n> - and, where a value is only used in one place, passing just that\n> value down instead of the whole repository.\n>\n> A lot of progress has already been made: many settings that used\n> to be globals now live in struct repo_config_values, and many files\n> no longer need the_repository. But there is still plenty left.\n> Over a hundred library files outside builtin/ still define\n> USE_THE_REPOSITORY_VARIABLE, and environment.h still has globals\n> such as git_commit_encoding, git_log_output_encoding and\n> comment_line_str. That remaining library code is where I want to\n> focus.\n\nIt's a good idea to focus on library code. You might also be\ninterested in what Junio says about code in \"builtin/\" in:\n\nhttps://lore.kernel.org/git/xmqqmru76ybk.fsf_-_@gitster.g/\n\n[...]\n\n> Roadblocks seen in earlier work\n> -------------------------------\n> - Not every global belongs in struct repository. When Ayush\n> Chandekar tried to move core.attributesfile into repo_settings,\n> Junio questioned whether attribute data belongs to a repository at\n> all, since attributes come from the index and the working tree,\n> and compared it to how index_state is passed around instead of the\n> repository [7]. The config value was later stored in struct\n> repo_config_values instead [5].\n> - State used during early startup cannot simply be moved; the setup\n> code has to change first. Patrick did this for\n> is_bare_repository_cfg and git_work_tree_cfg in his \"setup: drop\n> global state\" series [8]. have_git_dir() is still left, and\n> environment.h says it \"should not have to exist at all\".\n> - builtin/ commands: the \"repo\" argument of cmd_foo() can be NULL\n> (e.g. \"git foo -h\" outside a repository), so blindly replacing\n> the_repository there causes crashes. Library code is the safer\n> target.\n\nIn the discussion I mentioned above, Junio says that the code in\n\"builtin/\" isn't reusable library code at all, and that it would be\nuseful work to move that code into library helpers.\n\n[...]\n\n> Blogging\n> ========\n>\n> I will blog on Medium (https://medium.com/@okhuomonajayi54) and\n> post weekly updates on my progress, what I learned and the\n> challenges I faced. I will share each post on the mailing list,\n> like previous interns did.\n\nI wonder if blog posts on Medium are accessible to everyone.\n\nThanks.\n\n"},{"id":"557322","messageId":"CAFpMFfCX_VcBhyivh2f7vppYC4xLoYvUywAviW_73_nmOEkaeQ@mail.gmail.com","threadId":"66705","inReplyTo":"CAP8UFD1VUCTeXNbb4YKGkZRWY8i56Zms_=qkR2oqF7e1Aagy1Q@mail.gmail.com","subject":"Re: [Outreachy][Proposal]: Reduce Git's global state to enable Git's libification","fromName":"Okhuomon Ajayi","fromEmail":"okhuomonajayi54@gmail.com","sentAt":"2026-11-03T14:55:22Z","receivedAt":"2026-11-03T14:55:22Z","isPatch":false,"sender":{"key":"okhuomonajayi54@gmail.com","avatar":null},"body":"Hi Christian,\n\nOn Tue, Nov 3, 2026 at 2:46 PM Christian Couder\n wrote:\n> It's a good idea to focus on library code. You might also be\n> interested in what Junio says about code in \"builtin/\" in:\n>\n> https://lore.kernel.org/git/xmqqmru76ybk.fsf_-_@gitster.g/\n[...]\n> In the discussion I mentioned above, Junio says that the code in\n> \"builtin/\" isn't reusable library code at all, and that it would be\n> useful work to move that code into library helpers.\n\nThanks, I'll read that discussion and add moving code from builtin/\ninto library helpers to the plan in v2 of my proposal.\n\n> I wonder if blog posts on Medium are accessible to everyone.\n\nGood point, Medium can ask readers to sign in. I'll move my blog to\nHashnode / GitHub Pages so that anyone can read it without an\naccount.\n\nThanks for the review.\n\nOkhuomon\n\nOn Tue, Nov 3, 2026 at 2:46 PM Christian Couder\n wrote:\n>\n> Hi,\n>\n> On Thu, Oct 29, 2026 at 3:18 PM Okhuomon Ajayi\n> wrote:\n> >\n> > Hello,\n> >\n> > This is my proposal for the project \"Reduce Git's global state to\n> > enable Git's libification\" for the December 2026 Outreachy internship.\n>\n> Thanks for your interest in Git.\n>\n> > Past Experience with Git\n> > ========================\n> >\n> > I have been using Git since I started coding, for my own projects\n> > and when collaborating with other developers.\n> >\n> > This is not my first time on the Git mailing list. I applied to\n> > Outreachy in October 2025 and sent about ten patches in about a week\n> > (patch-ids, commit.c comments, builtin/patch-id.c, gpg-interface)\n> > [10]. None of them were merged. I was sending too fast, my subject\n> > lines had doubled prefixes like \"[PATCH] [PATCH v2]\", and my commit\n> > messages did not follow the project style, as Junio and Christian\n> > pointed out [11].\n> >\n> > This year I slowed down. I read SubmittingPatches properly, wrote\n> > my commit messages in the present tense, and sent one change at a\n> > time. The hardest part was still sending new versions: keeping each\n> > version in sync with the review, the right thread and the notes on\n> > what changed since the last version. This time my microproject was\n> > merged to master, and six more topics are in 'seen', some of\n> > them marked \"Will merge to 'next'?\" in What's cooking.\n>\n> Nice.\n>\n> > Reviews and help to other applicants\n> > ------------------------------------\n> > + list-objects-filter-options: pass repository to partial clone\n> > helpers (Dorine Tipo)\n> > My reply: https://lore.kernel.org/git/CAFpMFfCu6JrUC8i453qBP=AktqcG_9sGX=1-1ekEDCYm_+pkUw@mail.gmail.com/\n> > Description: Dorine asked whether USE_THE_REPOSITORY_VARIABLE\n> > could be dropped. I applied the patch, removed the define and\n> > checked that the file still builds, so it can go in the same\n> > patch.\n> >\n> > + Microproject idea: modernize a file-existence check in\n> > t/t0081-find-pack.sh (Immaculate Mecha)\n> > My reply: https://lore.kernel.org/git/CAFpMFfA17dnuLSRt97BrM0u3cHAifJybr_Zc2ahr_zq2nspgsw@mail.gmail.com/\n> > Description: Pointed out that Shashank S had already changed that\n> > exact line, and suggested searching lore and \"What's cooking\"\n> > before choosing a microproject.\n>\n> Thanks for helping with reviews.\n>\n> [...]\n>\n> > This project reduces that global state step by step:\n> > - removing the_repository from library code by passing the\n> > repository explicitly through the call chain, so files no longer\n> > need USE_THE_REPOSITORY_VARIABLE;\n> > - moving repository-specific settings from environment.c into the\n> > repository, mostly struct repo_config_values and struct\n> > repo_settings;\n> > - and, where a value is only used in one place, passing just that\n> > value down instead of the whole repository.\n> >\n> > A lot of progress has already been made: many settings that used\n> > to be globals now live in struct repo_config_values, and many files\n> > no longer need the_repository. But there is still plenty left.\n> > Over a hundred library files outside builtin/ still define\n> > USE_THE_REPOSITORY_VARIABLE, and environment.h still has globals\n> > such as git_commit_encoding, git_log_output_encoding and\n> > comment_line_str. That remaining library code is where I want to\n> > focus.\n>\n> It's a good idea to focus on library code. You might also be\n> interested in what Junio says about code in \"builtin/\" in:\n>\n> https://lore.kernel.org/git/xmqqmru76ybk.fsf_-_@gitster.g/\n>\n> [...]\n>\n> > Roadblocks seen in earlier work\n> > -------------------------------\n> > - Not every global belongs in struct repository. When Ayush\n> > Chandekar tried to move core.attributesfile into repo_settings,\n> > Junio questioned whether attribute data belongs to a repository at\n> > all, since attributes come from the index and the working tree,\n> > and compared it to how index_state is passed around instead of the\n> > repository [7]. The config value was later stored in struct\n> > repo_config_values instead [5].\n> > - State used during early startup cannot simply be moved; the setup\n> > code has to change first. Patrick did this for\n> > is_bare_repository_cfg and git_work_tree_cfg in his \"setup: drop\n> > global state\" series [8]. have_git_dir() is still left, and\n> > environment.h says it \"should not have to exist at all\".\n> > - builtin/ commands: the \"repo\" argument of cmd_foo() can be NULL\n> > (e.g. \"git foo -h\" outside a repository), so blindly replacing\n> > the_repository there causes crashes. Library code is the safer\n> > target.\n>\n> In the discussion I mentioned above, Junio says that the code in\n> \"builtin/\" isn't reusable library code at all, and that it would be\n> useful work to move that code into library helpers.\n>\n> [...]\n>\n> > Blogging\n> > ========\n> >\n> > I will blog on Medium (https://medium.com/@okhuomonajayi54) and\n> > post weekly updates on my progress, what I learned and the\n> > challenges I faced. I will share each post on the mailing list,\n> > like previous interns did.\n>\n> I wonder if blog posts on Medium are accessible to everyone.\n>\n> Thanks.\n\n"},{"id":"557411","messageId":"20261104083322.80687-1-okhuomonajayi54@gmail.com","threadId":"66705","inReplyTo":"20261029141818.40193-1-okhuomonajayi54@gmail.com","subject":"[Outreachy][Proposal v2]: Reduce Git's global state to enable Git's libification","fromName":"Okhuomon Ajayi","fromEmail":"okhuomonajayi54@gmail.com","sentAt":"2026-11-04T08:33:22Z","receivedAt":"2026-11-04T08:33:22Z","isPatch":false,"sender":{"key":"okhuomonajayi54@gmail.com","avatar":null},"body":"Hello,\n\nThis is the second version of my proposal for the project \"Reduce\nGit's global state to enable Git's libification\" for the December\n2026 Outreachy internship. v1 is here [16].\n \nChanges since v1\n----------------\n- Blog: moved from Medium to Hashnode, so that posts can be read\n without an account, as Christian pointed out [17].\n- Plan: added moving reusable code from builtin/ into library\n helpers, following the discussion Christian pointed to [18].\n- Plan: I will send related conversions as one series instead of\n many small topics, as Patrick asked [19].\n- Contributions: updated statuses, added the patches sent since v1,\n and what I learned from the notes-utils review [20].\n- Reviews: added my review of Srujith's submodule patch.\n\nI'd appreciate any feedback.\n\nPersonal Information\n====================\n\nFull Name: Okhuomon Rosemary Ajayi\nEmail: okhuomonajayi54@gmail.com\nGitHub: https://github.com/six-shot\nBlog: https://hashnode.com/@okhuomonajayi\nLocation: Lagos, Nigeria (WAT, UTC+1)\n\nAbout Me\n========\n\nI am Okhuomon Rosemary Ajayi, often known as \"sixshot\", a\nself-taught software developer from Lagos, Nigeria. I am obsessed\nwith robots and intelligent mechanical systems. C was the first\nprogramming language I picked up, before I moved into frontend and\nmobile development. Working on Git during this contribution period\nhas brought me back to C, and I have enjoyed working at that lower\nlevel again.\n\nBefore Git, I contributed to other open source projects. In Servo\nI fixed clippy warnings in the script crate and improved some\ndocumentation [12]. In the OCaml ecosystem I added Deflate support\nand horizontal differencing to ocaml-tiff, and worked on raven and\nYOCaml [13]. In LibreOffice I worked in the C++ core, fixing a bug\nwhere Infobar keys reached the document and cleaning up unit\nconversion code [14]. In Mozilla Firefox I fixed layout bugs in\nvertical tabs and split view [15].\n\nAs a woman in tech, I know how much it helps to see someone like\nyourself doing the work. That is why I volunteered to train girls at\nEdunity for Girls, helping them get started in tech.\n\nHonestly, I would like to be part of the Git community and keep on\ncontributing to open source. This project lets me do that in C, the\nlanguage I started with, and my patches on the_repository so far\nhave shown me how much there is to learn here.\n\nPast Experience with Git\n========================\n\nI have been using Git since I started coding, for my own projects\nand when collaborating with other developers.\n\nThis is not my first time on the Git mailing list. I applied to\nOutreachy in October 2025 and sent about ten patches in about a week\n(patch-ids, commit.c comments, builtin/patch-id.c, gpg-interface)\n[10]. None of them were merged. I was sending too fast, my subject\nlines had doubled prefixes like \"[PATCH] [PATCH v2]\", and my commit\nmessages did not follow the project style, as Junio and Christian\npointed out [11].\n\nThis year I slowed down. I read SubmittingPatches properly, wrote\nmy commit messages in the present tense, and sent one change at a\ntime. The hardest part was still sending new versions: keeping each\nversion in sync with the review, the right thread and the notes on\nwhat changed since the last version. This time my microproject was\nmerged to master, three more patches are in 'next' and marked \"Will\nmerge to 'master'\", and range-diff is on its way to 'next'.\n\nContributions to the Git Community\n==================================\n\nMicroproject\n------------\n+ delta-islands: use Q_() for island count\n Thread: https://lore.kernel.org/git/20261013203042.58610-1-okhuomonajayi54@gmail.com/\n Branch: oa/delta-islands-i18n-use-q\n Status: merged to 'master'\n Commit: 60e16b0387 (merge commit 7ac84b7267), listed in the\n Git 2.98.0 release notes\n Description: The island count in a progress message was built with\n a plain _() so translators could not handle plural forms. Use Q_()\n instead. v2 moved a reviewer note below the --- line after\n Junio's review.\n\nPatches related to the project (the_repository)\n------------------------------------------------\n+ merge: stop using the_repository\n Thread: https://lore.kernel.org/git/20261015142532.48175-1-okhuomonajayi54@gmail.com/\n Branch: oa/merge-without-the-repository\n Status: in 'seen'\n Description: Pass the repository already available at the entry\n points down to the helpers, removing the_repository and\n the_hash_algo from merge.c.\n\n+ merge-blobs: stop using the_repository\n Thread: https://lore.kernel.org/git/20261017105244.90295-1-okhuomonajayi54@gmail.com/\n Branch: oa/merge-blobs-stop-using-the-repository\n Status: in 'seen'\n Description: Use the repository reachable from the index_state\n instead of the global.\n Usman suggested renaming \"r\" to \"repo\"; Junio preferred the short\n \"r\" used elsewhere for \"struct repository *\", so I kept it [9].\n\n+ diffcore-break: remove USE_THE_REPOSITORY_VARIABLE\n Thread: https://lore.kernel.org/git/20261014114904.85300-1-okhuomonajayi54@gmail.com/\n Status: in 'next', marked \"Will merge to 'master'\"\n Description: An earlier commit removed the last use of\n the_repository in diffcore-break.c, so the file no longer needs\n USE_THE_REPOSITORY_VARIABLE. Drop the define.\n\n+ checkout: make unique_tracking_name() use the given repository\n (2 patches)\n Thread (v3): https://lore.kernel.org/git/20261023211533.73433-1-okhuomonajayi54@gmail.com/\n Status: v3 in 'seen'; Christian suggested unwrapping some lines\n now that they are shorter, which I will do in v4\n Description: Pass the repository to unique_tracking_name() and\n carry it in struct tracking_name_data, so checkout.c no longer\n needs USE_THE_REPOSITORY_VARIABLE. Usman asked for a clearer\n commit message in v1. In v2 Junio pointed out that the function\n still walked the remotes with for_each_remote(), which only works\n on the_repository, so v3 adds repo_for_each_remote() first.\n\n+ diffcore-rename: stop using the_repository\n Thread: https://lore.kernel.org/git/20261024221341.92086-1-okhuomonajayi54@gmail.com/\n Status: in 'next', marked \"Will merge to 'master'\"\n Description: diffcore_rename_extended() already has the\n repository through its options. Use its hash algorithm when\n checking for empty blobs, pass it to start_delayed_progress(),\n and drop USE_THE_REPOSITORY_VARIABLE. Patrick reviewed it and\n said it looks correct.\n\n+ notes-cache: read the cache ref from the given repository\n Thread: https://lore.kernel.org/git/20261026102603.32377-1-okhuomonajayi54@gmail.com/\n Status: reviewed by Junio, waiting to be queued\n Description: notes_cache_match_validity() already receives the\n repository but read the ref from the_repository. Pass it to\n get_main_ref_store() so the check reads the same repository.\n\n+ combine-diff: use the repository from diff options\n Thread: https://lore.kernel.org/git/20261026111303.92117-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: show_combined_header() and show_patch_diff()\n already have opt->repo; use it for the hash algorithm,\n abbreviation and gitlinks. The file still needs the macro for\n DEFAULT_ABBREV, which depends on the default_abbrev global.\n\n+ negotiator/default: stop using the_repository\n Thread (v2): https://lore.kernel.org/git/20261103155038.87456-1-okhuomonajayi54@gmail.com/\n Status: v2 sent after Christian's review (use the local variable\n I had introduced, and take the repository as the first argument,\n like most functions)\n Description: Give default_negotiator_init() a repository,\n store it on the negotiation state and use it to parse commits,\n clear marks and walk refs. Drop USE_THE_REPOSITORY_VARIABLE.\n\n+ bundle-uri: stop using the_repository\n Thread (v2): https://lore.kernel.org/git/20261029131325.79176-1-okhuomonajayi54@gmail.com/\n Status: v2 in 'next', marked \"Will merge to 'master'\"\n Description: unbundle_from_file() unbundles objects into the\n given repository but read and wrote refs in the_repository, and\n fetch_bundle_uri() used the_repository for tracing. v1 used the\n given repository for both and was reviewed by Karthik. Patrick\n then pointed out that only two more uses were left in the file,\n in find_temp_filename() and copy_uri_to_file(), so v2 passes the\n repository to them too and drops USE_THE_REPOSITORY_VARIABLE\n from bundle-uri.c.\n\n+ range-diff: use diffopt->repo instead of the_repository\n Thread (v2): https://lore.kernel.org/git/20261029084720.93221-1-okhuomonajayi54@gmail.com/\n Status: queued, marked \"Will merge to 'next'?\"\n Description: output_pair_header() and patch_diff() receive a\n diffopt that names the repository, but still used the_repository\n and the_hash_algo. Use diffopt->repo, and give get_filespec() a\n hash algorithm parameter. v2 rewords the commit message after\n Pablo's review.\n\n+ pseudo-merge: use writer->repo instead of the_repository\n Thread: https://lore.kernel.org/git/20261029194116.63464-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: The functions in pseudo-merge.c receive a\n bitmap_writer that names the repository, but used the_repository.\n Use writer->repo, give push_pseudo_merge() a repository\n parameter, and drop USE_THE_REPOSITORY_VARIABLE.\n\n+ name-hash: use istate->repo instead of the_repository\n Thread: https://lore.kernel.org/git/20261030183218.32630-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: Three functions receive the index but read\n core.ignoreCase through the_repository. Read it from istate->repo\n and drop USE_THE_REPOSITORY_VARIABLE.\n\n+ fsmonitor: stop using the_repository\n Thread: https://lore.kernel.org/git/20261031111450.66192-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: refresh_fsmonitor() gets its repository from the\n index, but the helpers it calls used the_repository. Pass the\n repository to fsmonitor_hook_version(), use the one the other\n helpers already have, and drop USE_THE_REPOSITORY_VARIABLE.\n\n+ wt-status: use the repository the status already has\n Thread: https://lore.kernel.org/git/20261101063951.85427-1-okhuomonajayi54@gmail.com/\n Status: sent, waiting for review\n Description: Use s->repo and r where the functions already have\n a repository. The define stays because DEFAULT_ABBREV expands to\n the global default_abbrev.\n\n+ notes-utils: use the passed repository (v1 -> v2, 2 patches)\n Thread (v2): https://lore.kernel.org/git/20261103084930.15532-1-okhuomonajayi54@gmail.com/\n Status: I will drop it, see below\n Description: v1 made create_notes_commit() and commit_notes()\n use the repository they are given. Patrick asked why I stopped\n short of dropping USE_THE_REPOSITORY_VARIABLE, so v2 also passed\n a repository to init_copy_notes_for_rewrite() and dropped it.\n Karthik found the patches good and dug into the history of the\n file. Junio then pointed out that dropping the define is\n misleading: the functions in notes.h that notes-utils.c calls\n still only work with the_repository, so notes.h has to be\n cleaned up first [20]. This taught me to follow the calls down\n before claiming a file no longer depends on the_repository.\n\n+ environment: move commit_encoding into repo_config_values\n Thread: https://lore.kernel.org/git/20261021155608.58509-1-okhuomonajayi54@gmail.com/\n Status: v1 reviewed by Junio; v2 in progress\n Description: v1 moved the global into struct repo_config_values.\n Junio pointed out that only commit.c uses it and suggested passing\n a \"const char *\" encoding down to the functions instead of the\n whole repository. v2 will do that.\n\nOther patches\n-------------\n+ credential-store: add lockTimeout config option (#leftoverbits)\n Thread (v2): https://lore.kernel.org/git/20261016212216.58000-1-okhuomonajayi54@gmail.com/\n Status: v2 sent after Junio's review, waiting\n Description: Junio noted in the rerere thread that\n credentialStore.lockTimeoutMS is the only timeout setting with\n the unit in its name, and suggested a synonym without \"MS\". Add\n credentialStore.lockTimeout; the old name keeps working.\n\nReviews and help to other applicants\n------------------------------------\n+ list-objects-filter-options: pass repository to partial clone\n helpers (Dorine Tipo)\n My reply: https://lore.kernel.org/git/CAFpMFfCu6JrUC8i453qBP=AktqcG_9sGX=1-1ekEDCYm_+pkUw@mail.gmail.com/\n Description: Dorine asked whether USE_THE_REPOSITORY_VARIABLE\n could be dropped. I applied the patch, removed the define and\n checked that the file still builds, so it can go in the same\n patch. Dorine added it to v2 with a Helped-by trailer.\n\n+ submodule: use the submodule repository to abbreviate commits\n (Srujith Poojary)\n My review: https://lore.kernel.org/git/CAFpMFfALb1KbEw-dc4wYCxS4PXfDBwzQOD6YPRe52_bpRnGt9w@mail.gmail.com/\n Description: Confirmed that the new test fails without the fix,\n and suggested describing the problem first, naming the code area\n in the title, choosing the repository once, and falling back to\n o->repo instead of the_repository. Srujith applied all of them\n in v2. On v2 I pointed out that \"git log\" on submodule.c always\n writes the area in lowercase, which he fixed in v3, and Junio\n queued the patch.\n\n+ Microproject idea: modernize a file-existence check in\n t/t0081-find-pack.sh (Immaculate Mecha)\n My reply: https://lore.kernel.org/git/CAFpMFfA17dnuLSRt97BrM0u3cHAifJybr_Zc2ahr_zq2nspgsw@mail.gmail.com/\n Description: Pointed out that Shashank S had already changed that\n exact line, and suggested searching lore and \"What's cooking\"\n before choosing a microproject.\n\nGit Rev News\n------------\n+ Proofread edition 140 and fixed typos in the Developer Spotlight\n interview (https://github.com/git/git.github.io/pull/878). It was\n merged, and I am credited in the published edition.\n\nLearning resource\n-----------------\n+ \"Learn C by reading Git\" -- a zero-to-hero guide\n Link: https://six-shot.github.io/six-shot-git-c-zero-to-hero/\n Description: C was the first language I learned, but I had not\n used it in a while. I built this guide during this Outreachy\n contribution period so I could understand C well by learning it\n with Git itself. It teaches C from zero using real code from\n git.git (repository.h, merge-blobs.c, git.c, ...), with\n exercises. It covers the patterns this project depends on:\n structs and pointers, passing \"struct repository *\" down a call\n chain, and why global variables like the_repository are a\n problem. I hope it also helps other people who want to start\n contributing to Git.\n\nProject Overview\n================\n\nGit keeps the state of the repository it is working on in a single\nglobal object, the_repository, which is a \"struct repository\". A\nlot of internal code uses this global directly instead of taking a\nrepository as a parameter. On top of that, many configuration and\nenvironment values are stored as global variables in environment.c\nrather than in the repository they belong to.\n\nThis design assumes that a process only ever works with one\nrepository. That is not true for things like submodules, and it is\none of the main things blocking the long-term goal of libifying Git,\nwhere a program could open several repositories at the same time.\nWith shared globals, two repositories in one process would read and\noverwrite the same values, which can lead to wrong behaviour that is\nhard to debug. It also makes the code harder to read and test,\nbecause a function's dependencies are hidden instead of being\nvisible in its parameters.\n\nThis project reduces that global state step by step:\n- removing the_repository from library code by passing the\n repository explicitly through the call chain, so files no longer\n need USE_THE_REPOSITORY_VARIABLE;\n- moving repository-specific settings from environment.c into the\n repository, mostly struct repo_config_values and struct\n repo_settings;\n- and, where a value is only used in one place, passing just that\n value down instead of the whole repository.\n\nA lot of progress has already been made: many settings that used\nto be globals now live in struct repo_config_values, and many files\nno longer need the_repository. But there is still plenty left.\nOver a hundred library files outside builtin/ still define\nUSE_THE_REPOSITORY_VARIABLE, and environment.h still has globals\nsuch as git_commit_encoding, git_log_output_encoding and\ncomment_line_str. That remaining library code is where I want to\nfocus.\n\nReview of Previous Work and Strategies\n======================================\n\nFrom reading past series on the list and from my own patches, I see\nthree strategies, and the right one depends on the variable:\n\n1. Thread the repository through the call chain, bottom-up.\n Patrick Steinhardt introduced USE_THE_REPOSITORY_VARIABLE so files\n that still depend on the global are marked [1]. Work then goes from\n the lowest layers up, removing the macro file by file (objects [2],\n path [3], packfile by Karthik [4]). My patches to merge.c,\n merge-blobs.c, diffcore-break.c, diffcore-rename.c, checkout.c,\n notes-cache.c, combine-diff.c, negotiator/default.c,\n bundle-uri.c and range-diff.c follow this pattern.\n\n2. Move repository-scoped config into the repository.\n core.hooksPath and core.sharedRepository moved into repo-settings\n with accessors [3]. Later, Olamide Caleb Bello's Outreachy series\n added struct repo_config_values, with repo_config_values(repo) as\n the accessor, and moved core.attributesFile, core.sparseCheckout\n and branch.autoSetupMerge into it [5]. Others, such as Tian Yuchen,\n have moved more values there since.\n\n3. Pass only the value the function needs.\n the_hash_algo was replaced by an explicit\n \"const struct git_hash_algo *\" in csum-file.c [2]. Junio asked for\n the same thing on my commit_encoding patch: since only commit.c\n uses the variable, pass the encoding string instead of adding it\n to repository config [6].\n\nRoadblocks seen in earlier work\n-------------------------------\n- Not every global belongs in struct repository. When Ayush\n Chandekar tried to move core.attributesfile into repo_settings,\n Junio questioned whether attribute data belongs to a repository at\n all, since attributes come from the index and the working tree,\n and compared it to how index_state is passed around instead of the\n repository [7]. The config value was later stored in struct\n repo_config_values instead [5].\n- State used during early startup cannot simply be moved; the setup\n code has to change first. Patrick did this for\n is_bare_repository_cfg and git_work_tree_cfg in his \"setup: drop\n global state\" series [8]. have_git_dir() is still left, and\n environment.h says it \"should not have to exist at all\".\n- builtin/ commands: the \"repo\" argument of cmd_foo() can be NULL\n (e.g. \"git foo -h\" outside a repository), so blindly replacing\n the_repository there causes crashes. Library code is the safer\n target.\n- Naming: Junio prefers a short \"r\" for \"struct repository *\"\n parameters [9], and most functions take it as their first\n argument.\n- Hidden dependencies: a file can pass a repository everywhere and\n still depend on the_repository through the functions it calls.\n For notes-utils.c, the notes.h functions underneath still only\n work with the_repository, so dropping the define there would\n have been misleading [20]. Before dropping a define I now follow\n the calls down into the other files.\n\nCan there be clear criteria? Only partly. My working checklist:\n a. Who reads and writes it? (git grep every use)\n b. Is it per-repository, per-index, per-subsystem or process-wide?\n c. Is it needed before a repository is set up?\n d. Does only one file use it? Then pass the value (strategy 3).\n e. Search the list for earlier attempts and objections first.\nAnything still unclear goes to the list as a question before code.\n\nExample: git_log_output_encoding\n--------------------------------\nThis is the encoding Git uses when it shows commit messages. It is\nthe twin of git_commit_encoding, which my commit_encoding patch\nworks on, but it is harder:\n\n- It is set in two places: from i18n.logOutputEncoding in\n environment.c, and from \"git log --encoding=...\" in revision.c.\n Other revision options like --reverse are stored in struct\n rev_info, but --encoding writes the global. The parsing was moved\n into revision.c in 2006 (7cbcf4d557) so that rev-list and\n diff-tree could use it too, and at that time the rest of the\n code read the encoding from a global anyway.\n\n- It is read through get_log_output_encoding() 15 times in 12\n files. Many of these callers (log-tree.c, bundle.c, submodule.c,\n sequencer.c) copy it into\n \"struct pretty_print_context.output_encoding\", so that struct\n already carries the value. That points to strategy 3: fill the\n context once from the caller and let the pretty-printing code use\n ctx->output_encoding instead of calling the global getter.\n\n- Some callers do not print a log: remote-curl.c uses it to\n re-encode an error message from the server, and sequencer.c uses\n it when building the todo list. So the value is really \"the\n user's display encoding\", not something that belongs to one\n repository. That is a reason NOT to put it in\n repo_config_values, which is also what Junio said about\n commit_encoding [6].\n\nMy plan for it: first do commit_encoding (single caller), then\npropose on the list storing the --encoding value in struct rev_info\nand passing it through pretty_print_context, and ask whether that\ndesign is acceptable before writing the series.\n\nInternship Plan and Timeline\n============================\n\nThe internship runs from 7 December 2026 to 8 March 2027.\n\nBefore the internship (now -- 6 Dec 2026)\n- Finish open patches: commit_encoding v2, checkout v4 and the\n others waiting for review. No new topics until those are\n reviewed.\n- Keep reviewing other applicants' patches in the global-state area.\n- Build a list of remaining globals and USE_THE_REPOSITORY_VARIABLE\n files outside builtin/, ordered by how low in the call graph they\n sit.\n\nWeeks 1-2 (7 Dec -- 20 Dec)\n- Agree the list and order with mentors.\n- First series: a group of related library files off\n USE_THE_REPOSITORY_VARIABLE, sent together instead of one topic\n per file [19].\n- First blog post.\n\nWeeks 3-6 (21 Dec -- 17 Jan)\n- environment.c globals that only one subsystem uses: pass the value\n down, as Junio suggested for commit_encoding.\n- git_log_output_encoding next: it is read in 12 files and also set\n by \"--encoding\", so agree the design on the list before coding.\n- Ask on the list before touching the comment_line_str group and the\n abbrev globals, since they are read in many places.\n\nWeeks 7-10 (18 Jan -- 14 Feb)\n- Continue bottom-up removal of the_repository in library code,\n one subsystem per series.\n- Move reusable code out of builtin/ into library helpers, which\n Junio describes as useful work because builtin/ code cannot be\n reused [18]. Agree candidates with mentors first.\n- Look at a harder item if mentors agree, such as have_git_dir(),\n which still depends on the_repository.\n\nWeeks 11-13 (15 Feb -- 8 Mar 2027)\n- Land rerolls, no new big series.\n- Final report on the blog and the list.\n- Update the \"Learn C by reading Git\" guide with what I learned.\n\nThroughout: related changes batched into one series, reply to\nreviews within a day or two,\nweekly blog post, weekly sync with mentors.\n\nAvailability\n============\n\nI can give 40 hours a week to the project during the internship.\nI am based in Lagos (WAT, UTC+1) and can adjust my hours for calls\nand reviews when needed.\n\nBlogging\n========\n\nI will blog on Hashnode (https://hashnode.com/@okhuomonajayi),\nwhich anyone can read without an account, and post weekly updates\non my progress, what I learned and the challenges I faced. I will\nshare each post on the mailing list, like previous interns did.\n\nAfter the Internship\n====================\n\nAfter the internship I want to continue as an open source\ncontributor to Git: sending patches, reviewing others' work and\nhelping new contributors get started, the way Usman and Junio\nhelped me. I also want to keep the \"Learn C by reading Git\" guide\nup to date so it stays useful for future applicants.\n\nAppreciation\n============\n\nI want to thank Usman and Junio for always helping out during this\ncontribution period. I also want to thank Patrick, Karthik, Pablo,\nChristian, Siddharth and Kaartic, who reviewed my work and gave me\nfeedback, and everyone in the Git community for being so welcoming.\n\nReferences\n==========\n[1] https://lore.kernel.org/git/cover.1718347699.git.ps@pks.im/\n[2] https://lore.kernel.org/git/20250306-b4-pks-objects-without-the-repository-v2-1-f3465327be69@pks.im/\n[3] https://lore.kernel.org/git/20250207-b4-pks-path-drop-the-repository-v2-14-13cad3c11b8a@pks.im/\n[4] https://lore.kernel.org/git/cover.1733236936.git.karthik.188@gmail.com/\n[5] https://lore.kernel.org/git/cover.1771258573.git.belkid98@gmail.com/\n[6] https://lore.kernel.org/git/xmqq33tyn5qi.fsf@gitster.g/\n[7] https://lore.kernel.org/git/xmqqwmcw97z2.fsf@gitster.g/\n[8] https://lore.kernel.org/git/20260611-b4-pks-setup-drop-global-state-v2-0-a6f7269c841d@pks.im/\n[9] https://lore.kernel.org/git/xmqqwlrcrqaz.fsf@gitster.g/\n[10] https://lore.kernel.org/git/20251009214445.1190274-1-okhuomonajayi54@gmail.com/\n[11] https://lore.kernel.org/git/CAP8UFD2sdvkv_ZqiLZU9k5zF+tM3UTQ8+mJjziRZGzOra6dMFA@mail.gmail.com/\n https://lore.kernel.org/git/xmqqo6q5z6iu.fsf@gitster.g/\n[12] https://github.com/servo/servo/pulls?q=is%3Apr+author%3Asix-shot+is%3Amerged\n[13] https://github.com/geocaml/ocaml-tiff/pull/80\n https://github.com/raven-ml/raven/pulls?q=is%3Apr+author%3Asix-shot\n https://github.com/xhtmlboi/yocaml/pulls?q=is%3Apr+author%3Asix-shot\n[14] https://gerrit.libreoffice.org/q/owner:okhuomonajayi54@gmail.com+status:merged\n https://whatsnew.libreoffice.org/25.8.4/\n[15] https://github.com/mozilla-firefox/firefox/commits?author=okhuomonajayi54@gmail.com\n[16] https://lore.kernel.org/git/20261029141818.40193-1-okhuomonajayi54@gmail.com/\n[17] https://lore.kernel.org/git/CAP8UFD1VUCTeXNbb4YKGkZRWY8i56Zms_=qkR2oqF7e1Aagy1Q@mail.gmail.com/\n[18] https://lore.kernel.org/git/xmqqmru76ybk.fsf_-_@gitster.g/\n[19] https://lore.kernel.org/git/auhtiZ86trLamccS@pks.im/\n[20] https://lore.kernel.org/git/xmqqjymt94l3.fsf@gitster.g/\n\nThanks for reading.\n\nOkhuomon Ajayi\n\n"},{"id":"557521","messageId":"CAPSxiM-8W4hefg9XxV_PFe+68H3sNUWqe00jeakDK8DRk3mvgg@mail.gmail.com","threadId":"66705","inReplyTo":"20261104083322.80687-1-okhuomonajayi54@gmail.com","subject":"Re: [Outreachy][Proposal v2]: Reduce Git's global state to enable Git's libification","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2026-11-05T00:16:08Z","receivedAt":"2026-11-05T00:16:08Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Wed, Nov 4, 2026 at 9:33 AM Okhuomon Ajayi wrote:\n>\n> Hello,\n\nThanks for your proposal. Do not forget to submit on the Outreachy website.\n\nThanks for your contributions and your interest in the Git project.\n\nThanks.\n\nUsman.\n\n"}]}