{"thread":{"id":"65040","subject":"[proposal][RFC] Improve the new git repo command","startedAt":"2026-02-22T07:57:21Z","lastAt":"2026-02-26T11:34:53Z","messageCount":4,"participants":["JAYATHEERTH K","Lucas Seiki Oshiro"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"536633","messageId":"CA+rGoLdSR=NPoD7XEbYPoRTt0VS5M0QhzHcy-OmyuZMMVN-H5w@mail.gmail.com","threadId":"65040","inReplyTo":null,"subject":"[proposal][RFC] Improve the new git repo command","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2026-02-22T07:57:09Z","receivedAt":"2026-02-22T07:57:21Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hi,\nI am done with a rough draft of my proposal,\ncurrently I am posting this in a text format but when I submit it officially\nI am planning to make it a TeX pdf.\n\n---\n\nImprove the new git repo command\nJayatheerth Kulkarni\nFebruary 22, 2026\n\n---\n\n1. About Me\nI am a junior at Geethanjali College of Engineering and Technology\npursuing a bachelor's degree, with a strong interest in open-source\nprojects and systems programming. My interest in the Git project\nstems from a desire to understand the internals of version control\nand contribute to a tool that is fundamental to the global software\ndevelopment ecosystem.\n\n1.1 Contact:\nemail: jayatheerthkulkarni2005@gmail.com\nwebsite: https://jayatheerth.com/\ngithub: https://github.com/jayatheerthkulkarni\nlinkedin: https://linkedin.com/in/jayatheerth\n\n1.2 Details related to projects:\nTimezone: Indian Standard Time (IST) / UTC+05:30\nMy Tech Stack: C, Shell Scripting, Rust\n\n---\n\n2. Contribution History\n\n2.1 Micro-Project (GSoC Requirement)\nTo familiarize myself with Git’s test suite and submission\nguidelines, I completed the following micro-project:\n\nPatch:\nhttps://lore.kernel.org/git/20260109032027.68680-1-jayatheerthkulkarni2005@gmail.com/\n[GSoC] t7101: modernize test path checks\nDescription: Replaced old-style test -[df] assertions with modern\ntest_path_is_* helpers in t7101-reset-empty-subdirs.sh. This\nimproves debuggability and aligns with modern Git coding standards.\nI also addressed path reference inaccuracies in the test\ndescriptions.\nStatus: Merged into master.\n\n2.1.1 A Micro-Patch to get started with repo.c codebase:\n\nPatch:\nhttps://lore.kernel.org/git/20260222004036.47744-1-jayatheerthkulkarni2005@gmail.com/T/#u\n[GSoC] builtin/repo: remove unused hex.h header\nDescription: This is a micro-patch that simply removes an unused\nheader to demonstrate my familiarity with the repo.c codebase and\nthe mailing list submission process.\n\n2.2 Taking part in the community\nFor many months, I have been a part of multiple discussions, one of\nwhich even got featured in Git Rev-News edition 124.\nhttps://git.github.io/rev_news/2025/06/30/edition-124/\n\nA list of my past activities in Git:\n\nJuly 2025\nsubmodule: skip redundant active entries when pattern covers path\nsubmodule: prevent overwriting .gitmodules on path reuse\nDiscussion link:\nhttps://lore.kernel.org/git/CA+rGoLdTT3kdELUyHdZLWyy8e6AbfRU7kDFcVUdCmVtDi11hMw@mail.gmail.com/T/#m1e53511686dccdccab4a1c484703472e5e739c6c\nStatus: Merged into master\n\nJune 2025\nstash: fix incorrect branch name in stash message\nDiscussion Link:\nhttps://lore.kernel.org/git/f46443ac-eb7f-47db-8f4b-a06384e6fde5@web.de/T/#m4b9a4c0da4f35519b3eb98bdc3d1fce84efa80aa\nStatus: Merged into master and featured in Git Rev-News\n(Discussions section)\n\nThese discussions highlight my ability to engage constructively\nwith the community and iterate on feedback.\n\n2.3 Experience with C:\nSince Git is mainly written in C, I would have no issues, as I am\nwell-versed in the language. I have received a Cisco CLP - Advanced\nC Programming certificate, which covered Unix and C in good detail.\nI have also taken two full semesters of C programming; therefore,\nI can confidently understand existing C code in Git.\n\n---\n\n3. Project Proposal\n\n3.1 Why \"Improve the new git repo command\"?\nThis project is particularly compelling because I have closely\nfollowed its development since its inception. Consistently reading\nthe weekly updates (https://lucasoshiro.github.io/gsoc-en/) and\nfollowing the mailing list patches for git repo info has deepened\nmy ongoing interest in this specific initiative since GSoC 2025.\nThis continuous engagement has provided a strong understanding of\nwhy the command exists and exactly what needs to be done.\n\n3.2 Introduction\nTaken from the SoC 2026 ideas page\n(https://git.github.io/SoC-2026-Ideas/), the new repo info command\nhas already started to be a really good replacement for parts of\nrev-parse. As this command is still in its early stages, there is\nsignificant opportunity to refine its architecture and expand its\nfeature set.\n\nArchitectural Changes:\n- Removing the global dependency on the_repository. This was a\n  project of its own in the past SoC 2025; now we implement this\n  in repo info.\n- Currently, we can access either all repository info or we can\n  access info manually. Adding a feature where we can access things\n  by category (e.g., git repo info paths returning git-dir,\n  common-dir, and worktree, or git repo info core returning all\n  core-related configurations) would be a good change to this\n  command.\n\nFeature Additions:\n- Adding path-related values currently obtained through git\n  rev-parse (such as git-dir, common-dir, toplevel, and\n  superproject-working-tree).\n- Adding more values currently obtained through git rev-parse\n  --git-path (such as the grafts file, index file, objects\n  directory, hooks directory, git-prefix, and other paths adjusted\n  by update_common_dir()).\n\n3.3 Proposed Solution and Objectives\nThe main objective of this project is to implement the changes and\nadditions discussed in the introduction to make git repo a complete,\nmodern replacement for parts of rev-parse. My proposed solutions are:\n\n- Removing the global state: The builtin/repo.c file currently opts\n  into using global state by declaring\n  #define USE_THE_REPOSITORY_VARIABLE at the top of the file. My\n  goal is to remove this macro entirely to align with Git's\n  libification efforts. To achieve this, I will refactor functions\n  that implicitly rely on this global state instead of the passed\n  repository context. For example, in get_layout_bare(), the repo\n  argument is currently marked as UNUSED because the function calls\n  is_bare_repository() (which checks global state). I will update\n  this and similar functions to evaluate the explicit repo struct\n  instead.\n\n- Implementing category keys: I will add a way to map specific\n  categories to a group of values. For example, if a user types\n  git repo info paths, the internal logic will look up the paths\n  category and return git-dir, common-dir, and other related\n  values all at once instead of requiring manual queries for each.\n\n- Adding path values: I will integrate the missing path values\n  currently obtained through git rev-parse (like toplevel and\n  superproject-working-tree) and --git-path (like index and hooks).\n  Since initial work on this has already started, my goal is to\n  take over the effort, lead the necessary design choices on the\n  mailing list, and complete the implementation.\n\n- Enhancing repo structure: I will study the external git-sizer\n  tool to figure out which of its repository analysis and\n  statistics features can be natively implemented into the git\n  repo structure sub-command.\n\n---\n\n4. Project Timeline\nFrom observing past GSoC proposal reviews, I understand that mailing\nlist discussions and patch iterations take time. I have structured\nthis timeline to be as realistic as possible, front-loading design\ndecisions and extending the schedule to accommodate standard review\ncycles.\n\n4.1 Community Bonding Period (May)\n- Attend the Git community GSoC sessions to introduce myself, the\n  project, and establish a communication schedule with my mentors.\n- Initiate the design discussion on the mailing list regarding the\n  output format for path-related values (absolute vs. relative\n  paths, or adding an --absolute-paths flag). Getting consensus\n  early is critical so coding can begin in Week 2.\n- Deep dive into path.c and setup.c to understand exactly how git\n  rev-parse currently resolves git-dir, common-dir, and --git-path\n  values.\n\n4.2 Phase 1: Core Implementation (Weeks 2 - 6)\nWeeks 2 and 3: Foundation and Extended Path Values\n- Implement the core path values currently obtained via git\n  rev-parse: git-dir, common-dir, toplevel, and\n  superproject-working-tree.\n- Implement the remaining values obtained via git rev-parse\n  --git-path: grafts file, index file, objects directory, hooks\n  directory, and git-prefix.\n- Write initial tests in t/ to ensure path resolution works\n  correctly across standard, bare, and worktree setups, then\n  submit the first patch series.\n\nWeeks 4 - 6: Removing Global State\n- Focus entirely on libification. Remove\n  #define USE_THE_REPOSITORY_VARIABLE from builtin/repo.c.\n- Refactor functions like get_layout_bare() that currently have an\n  UNUSED repo struct to evaluate the explicit repo parameter\n  instead of relying on global state.\n- Run the full test suite to ensure dropping the global state macro\n  does not introduce regressions, and submit the patch series.\n\n4.3 Mid-Term Evaluation Phase\n- Ensure the path-related additions and the global state removal\n  patches are either merged into master or queued in next.\n- Review progress with mentors, adjust the Phase 2 timeline based\n  on mailing list guidance, and submit the mid-term evaluation.\n\n4.4 Phase 2: Categories and Structure Enhancements (Weeks 7 - 12)\nWeeks 7 - 9: Category-Based Queries\n- Implement the internal mapping structure to associate category\n  keys (e.g., paths, layout) with their respective individual keys.\n- Modify the parsing logic in print_fields() and cmd_repo_info()\n  so that querying a category correctly loops through and outputs\n  the grouped values.\n- Add documentation and tests for the new category arguments.\n  Submit patches for review.\n\nWeeks 10 - 12: repo structure and git-sizer Integration\n- Analyze the codebase of git-sizer and identify the most valuable,\n  easily integrated metrics (e.g., maximum tree depth, massive blob\n  detection) that fit natively into Git's C codebase.\n- Implement these structural analysis additions into\n  cmd_repo_structure().\n- Ensure the new metrics correctly output in both the table format\n  and the NUL-terminated/keyvalue formats.\n\n4.5 Extended Period & Finalization (Weeks 13 - 14+)\nWeeks 13 - 14: Buffer and Edge Cases\n- This period acts as a realistic buffer for prolonged mailing list\n  discussions, particularly for the git-sizer integrations which\n  may require architectural feedback.\n- Perform rigorous edge-case testing (e.g., running the new\n  commands inside sparse checkouts, nested submodules, and heavily\n  customized .git/config environments) and address final patch\n  revisions.\n\nFinal Week: Documentation and Handoff\n- Finalize the official Git documentation for all new additions to\n  git repo info and git repo structure.\n- Clean up the commit history, ensure all patches are finalized on\n  the mailing list, and submit the final GSoC project report.\n\n---\n\n5. Availability and Blogging\nThis timeline aligns perfectly with my schedule. The project kicks\noff in May, during which I will be on summer vacation and can\ndedicate full-time hours. During June and July, I will transition\ninto my final year of university. My academic schedule during this\nperiod is highly flexible, allowing me to maintain a strong,\nconsistent level of activity and commit to the required hours.\n\nBlogging:\nI have a domain setup via Github pages at \"jayatheerth.com\" where\nI host my portfolio site. As weekly patches flow and the project\nprogresses, I will host a dedicated endpoint at \"/blogs\" to provide\ncomprehensive, weekly coverage of everything that is going on with\nmy project.\n\n---\n\n6. Post GSoC Commitment\nI actively follow the mailing list and intend to continue\ncontributing bug fixes and enhancements. I have been a part of the\nGit community since 2025 and hopefully will continue to be one for\na long time.\n\n\n\n\n--- End of proposal ---\n\n\nRegards\n- Jayatheerth\n"},{"id":"536667","messageId":"3C0852FD-59FE-496D-9521-E123181901B3@gmail.com","threadId":"65040","inReplyTo":"CA+rGoLdSR=NPoD7XEbYPoRTt0VS5M0QhzHcy-OmyuZMMVN-H5w@mail.gmail.com","subject":"Re: [proposal][RFC] Improve the new git repo command","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2026-02-22T21:14:20Z","receivedAt":"2026-02-22T21:14:35Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> A list of my past activities in Git:\n\nLooking the Git history (`git log --author='K Jayatheerth'`), there\nare many meaningful patches that you didn't listed here.\n\n> 3. Project Proposal\n> \n> 3.1 Why \"Improve the new git repo command\"?\n> This project is particularly compelling because I have closely\n> followed its development since its inception. Consistently reading\n> the weekly updates (https://lucasoshiro.github.io/gsoc-en/) and\n> following the mailing list patches for git repo info has deepened\n> my ongoing interest in this specific initiative since GSoC 2025.\n> This continuous engagement has provided a strong understanding of\n> why the command exists and exactly what needs to be done.\n\nThanks for your interest in my work :-).\n\n> 3.3 Proposed Solution and Objectives\n> The main objective of this project is to implement the changes and\n> additions discussed in the introduction to make git repo a complete,\n> modern replacement for parts of rev-parse. My proposed solutions are:\n> \n> - Removing the global state: The builtin/repo.c file currently opts\n>  into using global state by declaring\n>  #define USE_THE_REPOSITORY_VARIABLE at the top of the file. My\n>  goal is to remove this macro entirely to align with Git's\n>  libification efforts. To achieve this, I will refactor functions\n>  that implicitly rely on this global state instead of the passed\n>  repository context. For example, in get_layout_bare(), the repo\n>  argument is currently marked as UNUSED because the function calls\n>  is_bare_repository() (which checks global state). I will update\n>  this and similar functions to evaluate the explicit repo struct\n>  instead.\n> \n> - Implementing category keys: I will add a way to map specific\n>  categories to a group of values. For example, if a user types\n>  git repo info paths, the internal logic will look up the paths\n>  category and return git-dir, common-dir, and other related\n>  values all at once instead of requiring manual queries for each.\n> \n> - Adding path values: I will integrate the missing path values\n>  currently obtained through git rev-parse (like toplevel and\n>  superproject-working-tree) and --git-path (like index and hooks).\n>  Since initial work on this has already started, my goal is to\n>  take over the effort, lead the necessary design choices on the\n>  mailing list, and complete the implementation.\n> \n> - Enhancing repo structure: I will study the external git-sizer\n>  tool to figure out which of its repository analysis and\n>  statistics features can be natively implemented into the git\n>  repo structure sub-command.\n\nIt looks to me that you're proposing too much here. I mean, I agree\nwith everything that you proposed here, but maybe you won't have\nenough time to do that given the pace of the reviewing process. For\nexample, my first GSoC patch series took 11 versions until it was\naccepted.\n\n\n"},{"id":"536675","messageId":"CA+rGoLeq-bnxnzsYmgFg+Cj3uPW+30ApOMFT_wvrp9p9VRwnQg@mail.gmail.com","threadId":"65040","inReplyTo":"3C0852FD-59FE-496D-9521-E123181901B3@gmail.com","subject":"Re: [proposal][RFC] Improve the new git repo command","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2026-02-22T23:32:55Z","receivedAt":"2026-02-22T23:33:07Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey Lucas,\n\nThanks for taking time to review my proposal\n\n\nOn Mon, Feb 23, 2026 at 2:44 AM Lucas Seiki Oshiro\n<lucasseikioshiro@gmail.com> wrote:\n>\n>\n> > A list of my past activities in Git:\n>\n> Looking the Git history (`git log --author='K Jayatheerth'`), there\n> are many meaningful patches that you didn't listed here.\n>\n\nI agree, I think adding\nhttps://github.com/git/git/commit/ec727e189cce9e8457e2b00e0756cfdf325a12d9\nWould make sense too because that patch is path related\n\nBut the others are doc changes, do you suggest I add those too?\n\n\n\n\n>\n> It looks to me that you're proposing too much here. I mean, I agree\n> with everything that you proposed here, but maybe you won't have\n> enough time to do that given the pace of the reviewing process. For\n> example, my first GSoC patch series took 11 versions until it was\n> accepted.\n>\n\nAlright, this is tough because to me everything seems equally important\nSince you started this command, can you probably point out to me which\nof these in proposals are\nneeded urgently? as in which of these are high impact, and do you\nsuggest I remove the other parts?\n\nRegards\n- Jayatheerth\n"},{"id":"537181","messageId":"CA+rGoLcQUFPCZJt9Ph_1yQW_3zWg0Zuo9BSysF5mh-6Q7m2-mw@mail.gmail.com","threadId":"65040","inReplyTo":"3C0852FD-59FE-496D-9521-E123181901B3@gmail.com","subject":"Re: [GSoC proposal v2][RFC] Improve the new git repo command","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2026-02-26T11:34:40Z","receivedAt":"2026-02-26T11:34:53Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Since the last feedback from Lucas\nI have taken some time to improve my proposal\n\n- I have added all my patches that I raised in Git.\n- I have also taken up a much more realistic timeline.\n\n---\n\nImprove the new git repo command\nJayatheerth Kulkarni\nFebruary 26, 2026\n\n---\n\n1. About Me\nI am a junior at Geethanjali College of Engineering and Technology\npursuing a bachelor's degree, with a strong interest in open-source\nprojects and systems programming. My interest in the Git project\nstems from a desire to understand the internals of version control\nand contribute to a tool that is fundamental to the global software\ndevelopment ecosystem.\n\n1.1 Contact:\n- Email: jayatheerthkulkarni2005@gmail.com\n- Website: https://jayatheerth.com/\n- GitHub: https://github.com/jayatheerthkulkarni\n- LinkedIn: https://www.linkedin.com/in/jayatheerth/\n\n1.2 Logistics:\n- Timezone: Indian Standard Time (IST) / UTC+05:30\n- Tech Stack: C, Shell Scripting, Rust\n\n---\n\n2. Contribution History\n\nI have formally completed all the prerequisites to apply in\nGSoC `Improve the new git repo command` project.\n\nI have listed all of my work I have done in the past few months.\n\n2.1 Featured Contributions\nFor many months, I have been actively engaging with the Git community\nthrough mailing list discussions and patch submissions. Notably, my\nwork on fixing stash messaging behavior in submodule environments was\nfeatured in Git Rev-News edition 124.\n\n- [PATCH v3] stash: fix incorrect branch name in stash message\n  Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u\n  Status: Merged into master & featured in Git Rev-News.\n\n2.2 Core Path and Submodule Patches\n\n- [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse\n  Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u\n  Status: Merged into master.\n\n- [PATCH v2] dir: Fix and test wildcard pathspec handling\n  Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/\n  Status: Merged into master.\n\n2.3 Refactoring and Micro-Projects\nI am deeply familiar with Git's test suite and standard C conventions,\nhaving submitted several refactoring and cleanup patches, including\ntwo specific to the `builtin/repo.c` file:\n\n- [PATCH GSoC] repo: Remove unnecessary variable shadow\n  Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t\n  Status: Got a review from Justin.\n\n- [GSoC] t7101: modernize test path checks\n  Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t\n  Status: Merged into master (Official micro-project).\n\n- [PATCH v2] pull: move options[] array into function scope\n  Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u\n  Status: Merged to master.\n\n2.4 Documentation\nI have also contributed to updating community guidelines:\n- [PATCH v3] Update MyFirstContribution.adoc to follow modern practices\n  Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t\n\n2.5 Experience with C\nSince Git is mainly written in C, I have no issues navigating the\ncodebase. I hold a Cisco CLP - Advanced C Programming certificate\ncovering Unix and C systems programming, and I have completed two\nfull university semesters of C programming.\n\n---\n\n3. Project Proposal\n\n3.1 Why \"Improve the new git repo command\"?\nThis project is compelling because I have closely followed its\ndevelopment since its inception. Consistently reading the weekly\nupdates (https://lucasoshiro.github.io/gsoc-en/) and following the\nmailing list patches for `git repo info` has deepened my ongoing\ninterest in this specific initiative since GSoC 2025.\n\n3.2 Introduction\nTaken from the SoC 2026 ideas page, the new `repo info` command\nhas already started to be a good replacement for parts of `rev-parse`.\nAs this command is still in its early stages, there is significant\nopportunity to refine its architecture and expand its feature set.\nCurrently, many core functions in Git implicitly read environment\nvariables and store them as global states. To support Git's ongoing\n\"libification\" effort, these global dependencies must be removed.\n\n3.3 Proposed Solution and Objectives\nTo ensure realistic pacing and to respect the rigorous nature of Git's\nmailing list review cycle, I have scoped the primary objectives of this\nproject down to the two most critical milestones:\n\nObjective 1: Adding Path Values\nI will integrate the missing path values currently obtained through\n`git rev-parse` and `--git-path`. This includes:\n- `git-dir`, `common-dir`, `toplevel`, and `superproject-working-tree`.\n- The grafts file, index file, objects directory, hooks directory, and\n  `git-prefix`.\nImplementation: I will take over the initial design efforts on the\nmailing list, and finish the leftover work.\n\nObjective 2: Removing Global State\nThe `builtin/repo.c` file currently opts into using global state by\ndeclaring `#define USE_THE_REPOSITORY_VARIABLE`.\nImplementation: I will remove this macro entirely. Functions that\ncurrently implicitly rely on global state (e.g., `get_layout_bare()`,\nwhich currently marks its `repo` argument as `UNUSED`) will be\nrefactored. I will update these functions to evaluate the explicit\n`struct repository *repo` pointer, threading this context down the\ncall chain without breaking existing external callers.\n\n---\n\n4. Project Timeline\n\n4.1 Community Bonding Period (May 1 - May 24)\n- Attend the Git community GSoC sessions to introduce myself, the\n  project, and establish a communication schedule with my mentors.\n- Initiate the design discussion on the mailing list regarding the\n  output format for path-related values (absolute vs. relative paths).\n- Dive into existing efforts to map out exactly how resolves its current\n  path outputs.\n\n4.2 Phase 1: Core Path Implementation (May 25 - July 5)\nWeeks 1 - 3 (May 25 - June 14): Foundation and Extended Path Values\n- Implement the core path values (`git-dir`, `common-dir`, `toplevel`,\n  and `superproject-working-tree`).\n- Implement the remaining `--git-path` values.\n- Write initial tests in `t/` to ensure path resolution works correctly.\n\nWeeks 4 - 6 (June 15 - July 5): Review and Refinement\n- Address mailing list feedback for the path values patch series.\n- Begin mapping out the call chains affected by\n  `USE_THE_REPOSITORY_VARIABLE` in preparation for Phase 2.\n\n4.3 Mid-Term Evaluation Phase (July 6 - July 10)\n- Ensure the path-related additions are merged into master or queued\n  in the next.\n- Review progress with mentors and adjust the Phase 2 timeline if\n  necessary. Submit mid-term evaluation.\n\n4.4 Phase 2: Removing Global State (July 11 - August 16)\nWeeks 7 - 9 (July 11 - July 26): Threading the Context\n- Focus entirely on libification. Remove the global state macro from\n  `builtin/repo.c`.\n- Refactor functions like `get_layout_bare()` to utilize the explicit\n  `repo` parameter.\n- Carefully audit and update external callers to use the new API context.\n\nWeeks 10 - 12 (July 27 - August 16): Rigorous Testing and Iteration\n- This period acts as a realistic buffer for the anticipated multiple\n  versions required to get complex architectural refactoring merged.\n- Run the full test suite and perform rigorous edge-case testing\n  (e.g., sparse checkouts, nested submodules).\n\n4.5 Finalization (August 17 - August 24)\n- Finalize the official Git documentation for all new additions.\n- Clean up the commit history, ensure all patches are finalized on\n  the mailing list, and submit the final GSoC project report.\n\n4.6 Stretch Goals\nGiven the rigorous nature of Git's patch review process, my primary\ncommitment is to successfully merge the core path additions and the\nglobal state removal. However, if review cycles move faster than\nanticipated, I have prepared the following stretch goals:\n1. Category-Based Queries: Implementing an internal mapping structure\n   so users can query by category (e.g., `git repo info paths`).\n2. `repo structure` Enhancements: Analyzing the `git-sizer` codebase\n   to integrate native repository metrics into `cmd_repo_structure()`.\n\n---\n\n5. Availability and Blogging\nThis timeline aligns perfectly with my schedule. The project kicks\noff in May, during which I will be on summer vacation and can\ndedicate full-time hours. During June and July, I will transition\ninto my final year of university. My academic schedule during this\nperiod is highly flexible.\n\nBlogging:\nI have a domain setup at \"jayatheerth.com\". As patches flow and the\nproject progresses, I will host a dedicated endpoint at \"/blogs\" to\nprovide comprehensive, weekly coverage of my project.\n\n---\n\n6. Post GSoC Commitment\nI actively follow the mailing list and intend to continue\ncontributing bug fixes and enhancements. I have been a part of the\nGit community since 2025 and hopefully will continue to be one for\na long time.\n\n\n--- End of proposal ---\n\n\nRegards\n- Jayatheerth\n"}]}