{"thread":{"id":"65105","subject":"[GSoC][PROPOSAL] Improve the new git repo command","startedAt":"2026-03-01T03:11:00Z","lastAt":"2026-03-17T14:47:42Z","messageCount":3,"participants":["JAYATHEERTH K","Karthik Nayak","K Jayatheerth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537424","messageId":"CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com","threadId":"65105","inReplyTo":null,"subject":"[GSoC][PROPOSAL] Improve the new git repo command","fromName":"JAYATHEERTH K","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2026-03-01T03:10:48Z","receivedAt":"2026-03-01T03:11:00Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey everyone,\n\nThis is my proposal for the project\n`Improve the new git repo command`.\n\n---\n= GSoC 2026 PROPOSAL: IMPROVE THE NEW GIT REPO COMMAND\nJayatheerth Kulkarni <jayatheerthkulkarni2005@gmail.com>\nv1.0, March 1, 2026\n\n== 1. ABOUT ME\n\nI am a junior at Geethanjali College of Engineering and\nTechnology pursuing a bachelor's degree, with a strong\ninterest in open-source projects and systems programming.\nMy interest in the Git project stems from a desire to\nunderstand the internals of version control and contribute\nto a tool that is fundamental to the global software\ndevelopment ecosystem.\n\n=== 1.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\n=== 1.2 Logistics\n* Timezone: Indian Standard Time (IST) / UTC+05:30\n* Tech Stack: C, Shell Scripting, Rust and Go\n\n== 2. CONTRIBUTION HISTORY\n\nI have formally completed all the prerequisites to apply\nfor the GSoC \"Improve the new git repo command\" project.\nI have listed all of my work I have done in the past few\nmonths.\n\n=== 2.1 Featured Contributions\n\nFor many months, I have been actively engaging with the\nGit community through mailing list discussions and patch\nsubmissions. Notably, my work on fixing stash messaging\nbehavior in submodule environments was featured in Git\nRev-News edition 124.\n\n* [PATCH v3] stash: fix incorrect branch name in stash message*\n  Status: Merged into `master` & featured in Git Rev-News.\n  Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u\n\n=== 2.2 Core Path and Submodule Patches\n\n* [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse*\n  Status: Merged into `master`.\n  Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u\n\n* [PATCH v2] dir: Fix and test wildcard pathspec handling*\n  Status: Merged into `master`.\n  Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/\n\n=== 2.3 Refactoring and Micro-Projects\n\nI am deeply familiar with Git's test suite and standard\nC conventions, having submitted several refactoring and\ncleanup patches, including two specific to the\n`builtin/repo.c` file:\n\n* [PATCH GSoC] repo: Remove unnecessary variable shadow*\n  Status: Merged into `next`\n  Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t\n\n* [GSoC] t7101: modernize test path checks*\n  Status: Merged into `master` (Official micro-project).\n  Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t\n\n* [PATCH v2] pull: move options[] array into function scope*\n  Status: Merged to `master`.\n  Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u\n\n=== 2.4 Documentation\n\n* [PATCH v3] Update MyFirstContribution.adoc to follow modern practices*\n  Status: Merged to `master`.\n  Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t\n\n=== 2.5 Experience with C\n\nSince Git is mainly written in C, I have no issues\nnavigating the codebase. I hold a Cisco CLP - Advanced C\nProgramming certificate covering Unix and C systems\nprogramming, and I have completed two full university\nsemesters of C programming.\n\n== 3. PROJECT PROPOSAL\n\n=== 3.1 Why \"Improve the new git repo command\"?\n\nThis project is compelling because I have closely followed\nits development since its inception in GSoC 2025.\nConsistently reading the weekly updates\n(https://lucasoshiro.github.io/gsoc-en/) and participating\nin the mailing list discussions has given me a deep\nunderstanding of the command's architecture.\nMy previous work fixing cross-platform wildcard pathspecs\nin `dir.c` makes me uniquely suited to tackle the path\nresolution this project requires, while my C systems\nexperience prepares me for the architectural refactoring\nof the command.\n\n=== 3.2 Introduction\n\nThe new `git repo info` command is positioned to be a\ncleaner, programmatic replacement for scraping\n`git rev-parse`. However, its current implementation lacks\ncategory-based querying, relies on global state macros,\nand is missing critical path data.\nTo fully realize Git's libification effort and improve\nuser experience, the internal architecture of\n`builtin/repo.c` must be modernized.\n\n=== 3.3 Proposed Solution and Objectives\n\nInstead of just scraping basic paths, I propose an\narchitectural update to `repo info`, safely utilizing the\nnew `strbuf_add_path` API submitted by Lucas Oshiro.\n\n*Objective 1: Category-Based Query Architecture (The Core API)* +\nCurrently, the `repo_info_fields` array relies on an\nexact-match binary search (`bsearch`). Users must request\nspecific keys or use `--all`.\nI will rewrite the lookup logic to support\ncategory-prefix matching.\n* *Implementation:* I will implement an internal mapping\n  structure so that calling `git repo info path`\n  successfully identifies the category root and iterates\n  through all keys starting with `path.*`, returning them\n  dynamically.\n\n*Objective 2: Deep Libification (Removing Global State)* +\nThe `builtin/repo.c` file is already highly modernized,\nbut it opts into global state by declaring\n`USE_THE_REPOSITORY_VARIABLE` at the top of the file.\n* *Implementation:* I will remove this macro entirely.\n  The primary blocker in this file is `get_layout_bare()`,\n  which currently marks its local `repo` argument as\n  `UNUSED` and falls back to the global\n  `is_bare_repository()` helper.\n  I will refactor this function to drop the `UNUSED` tag\n  and explicitly evaluate the passed\n  `struct repository *repo` pointer.\n  I will thread this context down the call chain without\n  breaking existing external callers.\n\n*Objective 3: Core Path Resolution (`git rev-parse` parity)* +\nWith the category API built, I will populate the `path.*`\ncategory by implementing the remaining path values currently\nobtained through `git rev-parse` and `--git-path`.\nLucas Oshiro's recent patch series implemented `path.toplevel`;\nhttps://lore.kernel.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/T/#t\nI will build upon this foundation to implement the rest.\nBecause path normalizations across different systems are\ncomplex, I will leverage my experience from `dir.c` to safely implement:\n* `path.git-dir`, `path.common-dir`, `path.worktree`.\n* `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.\n\n*Objective 4: Sparse Topology & Boundary Awareness* +\nModern Git workflows rely heavily on partial checkouts\nand submodules, and `repo info` should report these\ncomplex states natively.\n* *Implementation:* I will implement `layout.is-sparse`\n  to expose if the repository uses a sparse-checkout\n  cone, and `path.superproject-working-tree` to instantly\n  query if the current repository is a submodule.\n\n== 4. PROJECT TIMELINE\n\n=== 4.1 Community Bonding Period (May 1 - May 24)\n\n* Attend the Git community GSoC sessions to introduce\n  myself and establish a communication schedule.\n* Initiate the design discussion on the mailing list\n  regarding the internal data structure for\n  Category-Based Queries.\n* Map out the exact C call chains affected by\n  `USE_THE_REPOSITORY_VARIABLE` in `builtin/repo.c`.\n\n=== 4.2 Phase 1: Category Architecture & Core Paths\n(May 25 - July 5)\n\n*Weeks 1 - 3 (May 25 - June 14):*\n* Implement the category-based lookup mechanism in\n  `builtin/repo.c`.\n* Update the parsing logic so `git repo info <category>`\n  successfully returns all nested keys.\n\n*Weeks 4 - 6 (June 15 - July 5):*\n* Utilize Lucas's `strbuf_add_path` API to implement the\n  core path values.\n* Implement path related keys.\n  (`path.git-dir`, `path.common-dir`, `path.worktree`,\n   `path.objects`, `path.hooks`, `path.index`, and `path.grafts`)\n* Write rigorous OS-agnostic tests in `t/` to ensure path\n  resolution works correctly across POSIX and Windows\n  environments.\n\n=== 4.3 Mid-Term Evaluation Phase (July 6 - July 10)\n\n* Ensure the category architecture and core paths are\n  merged into `master` or queued in `next`.\n* Review progress with mentors and adjust the Phase 2\n  timeline if necessary.\n* Submit mid-term evaluation.\n\n=== 4.4 Phase 2: Removing Global State & Sparse Topology\n(July 11 - August 16)\n\n*Weeks 7 - 9 (July 11 - July 26):*\n* Focus entirely on libification.\n* Remove the `USE_THE_REPOSITORY_VARIABLE` macro from\n  `builtin/repo.c`.\n* Refactor `get_layout_bare()` and similar functions to\n  utilize the explicit `repo` parameter.\n\n*Weeks 10 - 12 (July 27 - August 16):*\n* Implement the advanced topology and boundary keys\n  (`layout.is-sparse` and `path.superproject-working-tree`).\n* Run the full test suite and perform rigorous edge-case\n  testing ensuring libification does not cause\n  regressions.\n* Buffer period for addressing mailing list feedback\n  regarding the libification and sparse patches.\n\n=== 4.5 Finalization (August 17 - August 24)\n\n* Finalize the official Git documentation\n  (`Documentation/git-repo.txt`) for all new keys and\n  category querying.\n* Clean up the commit history and ensure all patches are\n  finalized on the mailing list.\n* Submit the final GSoC project report.\n\n=== 4.6 Stretch Goals\n\nIf review cycles move faster than anticipated, I will\nimplement Split-Index Topology (`path.shared-index`)\nto report the path to the shared index file. I will\nalso investigate natively parsing `git-sizer` metrics\ninto the newly established category API to provide\ndeeper repository health insights.\n\n== 5. AVAILABILITY AND BLOGGING\n\nThis timeline aligns perfectly with my schedule.\nThe project kicks off in May, during which I will be on\nsummer vacation and can dedicate 35-50 hours a week.\nDuring June and July, I will transition into my final\nyear of university.\nMy academic schedule during this period is highly\nflexible.\n\n*Blogging:* +\nI have a domain setup at jayatheerth.com.\nAs patches flow and the project progresses, I will host a\ndedicated endpoint at `/blogs` to provide comprehensive,\nweekly coverage of my project.\n\n== 6. POST GSOC COMMITMENT\n\nI actively follow the mailing list and intend to continue\ncontributing bug fixes and enhancements.\nI have been a part of the Git community since 2025 and\nhopefully will continue to be one for a long time.\n\n--- End of proposal ---\n\nRegards\n- Jayatheerth\n"},{"id":"539212","messageId":"CAOLa=ZS6HtJrWd0kfsFASCbP2S9-MQq5Da3feA0WqY8ykZ0WTw@mail.gmail.com","threadId":"65105","inReplyTo":"CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL] Improve the new git repo command","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-03-17T10:44:49Z","receivedAt":"2026-03-17T10:44:51Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:\n\nHello,\n\n> Hey everyone,\n>\n> This is my proposal for the project\n> `Improve the new git repo command`.\n>\n> ---\n> = GSoC 2026 PROPOSAL: IMPROVE THE NEW GIT REPO COMMAND\n> Jayatheerth Kulkarni <jayatheerthkulkarni2005@gmail.com>\n> v1.0, March 1, 2026\n>\n> == 1. ABOUT ME\n>\n> I am a junior at Geethanjali College of Engineering and\n> Technology pursuing a bachelor's degree, with a strong\n> interest in open-source projects and systems programming.\n> My interest in the Git project stems from a desire to\n> understand the internals of version control and contribute\n> to a tool that is fundamental to the global software\n> development ecosystem.\n>\n> === 1.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>\n> === 1.2 Logistics\n> * Timezone: Indian Standard Time (IST) / UTC+05:30\n> * Tech Stack: C, Shell Scripting, Rust and Go\n>\n> == 2. CONTRIBUTION HISTORY\n>\n> I have formally completed all the prerequisites to apply\n> for the GSoC \"Improve the new git repo command\" project.\n> I have listed all of my work I have done in the past few\n> months.\n>\n> === 2.1 Featured Contributions\n>\n> For many months, I have been actively engaging with the\n> Git community through mailing list discussions and patch\n> submissions. Notably, my work on fixing stash messaging\n> behavior in submodule environments was featured in Git\n> Rev-News edition 124.\n>\n> * [PATCH v3] stash: fix incorrect branch name in stash message*\n>   Status: Merged into `master` & featured in Git Rev-News.\n>   Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u\n>\n> === 2.2 Core Path and Submodule Patches\n>\n> * [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse*\n>   Status: Merged into `master`.\n>   Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u\n>\n> * [PATCH v2] dir: Fix and test wildcard pathspec handling*\n>   Status: Merged into `master`.\n>   Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/\n>\n> === 2.3 Refactoring and Micro-Projects\n>\n> I am deeply familiar with Git's test suite and standard\n> C conventions, having submitted several refactoring and\n> cleanup patches, including two specific to the\n> `builtin/repo.c` file:\n>\n> * [PATCH GSoC] repo: Remove unnecessary variable shadow*\n>   Status: Merged into `next`\n>   Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t\n>\n> * [GSoC] t7101: modernize test path checks*\n>   Status: Merged into `master` (Official micro-project).\n>   Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t\n>\n> * [PATCH v2] pull: move options[] array into function scope*\n>   Status: Merged to `master`.\n>   Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u\n>\n> === 2.4 Documentation\n>\n> * [PATCH v3] Update MyFirstContribution.adoc to follow modern practices*\n>   Status: Merged to `master`.\n>   Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t\n>\n> === 2.5 Experience with C\n>\n> Since Git is mainly written in C, I have no issues\n> navigating the codebase. I hold a Cisco CLP - Advanced C\n> Programming certificate covering Unix and C systems\n> programming, and I have completed two full university\n> semesters of C programming.\n>\n> == 3. PROJECT PROPOSAL\n>\n> === 3.1 Why \"Improve the new git repo command\"?\n>\n> This project is compelling because I have closely followed\n> its development since its inception in GSoC 2025.\n> Consistently reading the weekly updates\n> (https://lucasoshiro.github.io/gsoc-en/) and participating\n> in the mailing list discussions has given me a deep\n> understanding of the command's architecture.\n> My previous work fixing cross-platform wildcard pathspecs\n> in `dir.c` makes me uniquely suited to tackle the path\n> resolution this project requires, while my C systems\n> experience prepares me for the architectural refactoring\n> of the command.\n>\n> === 3.2 Introduction\n>\n> The new `git repo info` command is positioned to be a\n> cleaner, programmatic replacement for scraping\n> `git rev-parse`. However, its current implementation lacks\n> category-based querying, relies on global state macros,\n> and is missing critical path data.\n> To fully realize Git's libification effort and improve\n> user experience, the internal architecture of\n> `builtin/repo.c` must be modernized.\n>\n> === 3.3 Proposed Solution and Objectives\n>\n> Instead of just scraping basic paths, I propose an\n> architectural update to `repo info`, safely utilizing the\n> new `strbuf_add_path` API submitted by Lucas Oshiro.\n>\n> *Objective 1: Category-Based Query Architecture (The Core API)* +\n> Currently, the `repo_info_fields` array relies on an\n> exact-match binary search (`bsearch`). Users must request\n> specific keys or use `--all`.\n> I will rewrite the lookup logic to support\n> category-prefix matching.\n> * *Implementation:* I will implement an internal mapping\n>   structure so that calling `git repo info path`\n>   successfully identifies the category root and iterates\n>   through all keys starting with `path.*`, returning them\n>   dynamically.\n>\n\nThis would definitely be nice to have. Have you also thought about glob\npattern matching too? That way a user could do\n\n  $ git repo info \"path*\"\n\nAnd have it list all keys which start with path. Similar to how you plan\nto do category matching, but this can also do\n\n  $ git repo info \"*object*\"\n\nSo any keys with object in it would match too. Either ways I'm just\nthinking out loud and not saying this is what you _should_ do.\n\n> *Objective 2: Deep Libification (Removing Global State)* +\n> The `builtin/repo.c` file is already highly modernized,\n> but it opts into global state by declaring\n> `USE_THE_REPOSITORY_VARIABLE` at the top of the file.\n> * *Implementation:* I will remove this macro entirely.\n>   The primary blocker in this file is `get_layout_bare()`,\n>   which currently marks its local `repo` argument as\n>   `UNUSED` and falls back to the global\n>   `is_bare_repository()` helper.\n>   I will refactor this function to drop the `UNUSED` tag\n>   and explicitly evaluate the passed\n>   `struct repository *repo` pointer.\n>   I will thread this context down the call chain without\n>   breaking existing external callers.\n>\n\nIt would be nice to collate some of the efforts already made in this\ndirection, I know its not as simple [1] as passing in the repo since\n`is_bare_repository()` has a lot of callees.\n\n> *Objective 3: Core Path Resolution (`git rev-parse` parity)* +\n> With the category API built, I will populate the `path.*`\n> category by implementing the remaining path values currently\n> obtained through `git rev-parse` and `--git-path`.\n> Lucas Oshiro's recent patch series implemented `path.toplevel`;\n> https://lore.kernel.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/T/#t\n> I will build upon this foundation to implement the rest.\n> Because path normalizations across different systems are\n> complex, I will leverage my experience from `dir.c` to safely implement:\n> * `path.git-dir`, `path.common-dir`, `path.worktree`.\n> * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.\n>\n\nThis is the crux, but you should also probably involve some of the newer\ndiscussions around this. I added some pointers to Mansi's proposal, and\nperhaps that's something you should look into too. [2]\n\n> *Objective 4: Sparse Topology & Boundary Awareness* +\n> Modern Git workflows rely heavily on partial checkouts\n> and submodules, and `repo info` should report these\n> complex states natively.\n> * *Implementation:* I will implement `layout.is-sparse`\n>   to expose if the repository uses a sparse-checkout\n>   cone, and `path.superproject-working-tree` to instantly\n>   query if the current repository is a submodule.\n>\n\nThose may be good additions.\n\n> == 4. PROJECT TIMELINE\n>\n> === 4.1 Community Bonding Period (May 1 - May 24)\n>\n> * Attend the Git community GSoC sessions to introduce\n>   myself and establish a communication schedule.\n> * Initiate the design discussion on the mailing list\n>   regarding the internal data structure for\n>   Category-Based Queries.\n> * Map out the exact C call chains affected by\n>   `USE_THE_REPOSITORY_VARIABLE` in `builtin/repo.c`.\n>\n> === 4.2 Phase 1: Category Architecture & Core Paths\n> (May 25 - July 5)\n>\n> *Weeks 1 - 3 (May 25 - June 14):*\n> * Implement the category-based lookup mechanism in\n>   `builtin/repo.c`.\n> * Update the parsing logic so `git repo info <category>`\n>   successfully returns all nested keys.\n>\n> *Weeks 4 - 6 (June 15 - July 5):*\n> * Utilize Lucas's `strbuf_add_path` API to implement the\n>   core path values.\n> * Implement path related keys.\n>   (`path.git-dir`, `path.common-dir`, `path.worktree`,\n>    `path.objects`, `path.hooks`, `path.index`, and `path.grafts`)\n> * Write rigorous OS-agnostic tests in `t/` to ensure path\n>   resolution works correctly across POSIX and Windows\n>   environments.\n\nI think this will take way more time than the two weeks allocated here,\nmostly because of the design decisions we need finalize on.\n\n>\n> === 4.3 Mid-Term Evaluation Phase (July 6 - July 10)\n>\n> * Ensure the category architecture and core paths are\n>   merged into `master` or queued in `next`.\n> * Review progress with mentors and adjust the Phase 2\n>   timeline if necessary.\n> * Submit mid-term evaluation.\n>\n> === 4.4 Phase 2: Removing Global State & Sparse Topology\n> (July 11 - August 16)\n>\n> *Weeks 7 - 9 (July 11 - July 26):*\n> * Focus entirely on libification.\n> * Remove the `USE_THE_REPOSITORY_VARIABLE` macro from\n>   `builtin/repo.c`.\n> * Refactor `get_layout_bare()` and similar functions to\n>   utilize the explicit `repo` parameter.\n>\n> *Weeks 10 - 12 (July 27 - August 16):*\n> * Implement the advanced topology and boundary keys\n>   (`layout.is-sparse` and `path.superproject-working-tree`).\n> * Run the full test suite and perform rigorous edge-case\n>   testing ensuring libification does not cause\n>   regressions.\n> * Buffer period for addressing mailing list feedback\n>   regarding the libification and sparse patches.\n>\n\nOverall I think this is trying to do many things in a short time frame.\nI would also consider the time it takes for reviews and iterations to\nland.\n\n> === 4.5 Finalization (August 17 - August 24)\n>\n> * Finalize the official Git documentation\n>   (`Documentation/git-repo.txt`) for all new keys and\n>   category querying.\n> * Clean up the commit history and ensure all patches are\n>   finalized on the mailing list.\n> * Submit the final GSoC project report.\n>\n> === 4.6 Stretch Goals\n>\n> If review cycles move faster than anticipated, I will\n> implement Split-Index Topology (`path.shared-index`)\n> to report the path to the shared index file. I will\n> also investigate natively parsing `git-sizer` metrics\n> into the newly established category API to provide\n> deeper repository health insights.\n>\n> == 5. AVAILABILITY AND BLOGGING\n>\n> This timeline aligns perfectly with my schedule.\n> The project kicks off in May, during which I will be on\n> summer vacation and can dedicate 35-50 hours a week.\n> During June and July, I will transition into my final\n> year of university.\n> My academic schedule during this period is highly\n> flexible.\n>\n> *Blogging:* +\n> I have a domain setup at jayatheerth.com.\n> As patches flow and the project progresses, I will host a\n> dedicated endpoint at `/blogs` to provide comprehensive,\n> weekly coverage of my project.\n>\n> == 6. POST GSOC COMMITMENT\n>\n> I actively follow the mailing list and intend to continue\n> contributing bug fixes and enhancements.\n> I have been a part of the Git community since 2025 and\n> hopefully will continue to be one for a long time.\n>\n> --- End of proposal ---\n>\n> Regards\n> - Jayatheerth\n\nRegards,\nKarthik\n\n[1]: https://lore.kernel.org/git/xmqqbji0b5ak.fsf@gitster.g/#t\n[2]: CAOLa=ZTtNSZ904v0-SN16jAis7gK4=MVj1g_5CGdbmaBopeZkg@mail.gmail.com\n"},{"id":"539222","messageId":"CA+rGoLe70x2Ns5e8qHm3n-yvNxQbAc1b=Mqm31GDsMCOfJjNFw@mail.gmail.com","threadId":"65105","inReplyTo":"CAOLa=ZS6HtJrWd0kfsFASCbP2S9-MQq5Da3feA0WqY8ykZ0WTw@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL] Improve the new git repo command","fromName":"K Jayatheerth","fromEmail":"jayatheerthkulkarni2005@gmail.com","sentAt":"2026-03-17T14:47:29Z","receivedAt":"2026-03-17T14:47:42Z","isPatch":false,"sender":{"key":"jayatheerthkulkarni2005@gmail.com","avatar":"https://avatars.githubusercontent.com/u/148841023?v=4"},"body":"Hey Karthik,\n\nThank you for taking time to go through the proposal.\n\n\n> > * *Implementation:* I will implement an internal mapping\n> >   structure so that calling `git repo info path`\n> >   successfully identifies the category root and iterates\n> >   through all keys starting with `path.*`, returning them\n> >   dynamically.\n> >\n>\n> This would definitely be nice to have. Have you also thought about glob\n> pattern matching too? That way a user could do\n>\n>   $ git repo info \"path*\"\n>\n> And have it list all keys which start with path. Similar to how you plan\n> to do category matching, but this can also do\n>\n>   $ git repo info \"*object*\"\n>\n> So any keys with object in it would match too. Either ways I'm just\n> thinking out loud and not saying this is what you _should_ do.\n>\n\nI hadn't thought about globbing till now\nbut I have now given it a thought, I personally believe we don't need\nglobs (at least not now)\n\nThere are hardly 4 elements in the array `repo_info_field` as of now\neven if we add all the paths I think it will not go beyond 20 elements.\nAnd I think globbing is a problem we would have to debate after we get\nto >= 30 elements,\nglobbing has its advantages, it gets insanely flexible but I don't\nbelieve it is a current problem.\nI could however add an RFC in the community bonding period.\n\n\n> >   and explicitly evaluate the passed\n> >   `struct repository *repo` pointer.\n> >   I will thread this context down the call chain without\n> >   breaking existing external callers.\n> >\n>\n> It would be nice to collate some of the efforts already made in this\n> direction, I know its not as simple [1] as passing in the repo since\n> `is_bare_repository()` has a lot of callees.\n>\n\nAfter posting this proposal\nI was tweaking around and found out repo->worktree\nIt holding a `NULL` value is directly supposed to indicate it is\n`bare` if I am correct?\n\nI maybe wrong here\nBut writing up a quick change where\n\nstatic int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n{\nstrbuf_addstr(buf, is_bare_repository() ? \"true\" : \"false\");\nreturn 0;\n}\n\nbecomes\n\nstatic int get_layout_bare(struct repository *repo, struct strbuf *buf)\n{\nstrbuf_addstr(buf, (repo->worktree == NULL) ? \"true\" : \"false\");\nreturn 0;\n}\n\nand removing the macro\n#define USE_THE_REPOSITORY_VARIABLE\n\nwould work is what I have dug so far\nI would of course not send a patch until GSoC starts\nBut I wanted to know if I am thinking in the right direction here?\n\n\n> > * `path.git-dir`, `path.common-dir`, `path.worktree`.\n> > * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.\n> >\n>\n> This is the crux, but you should also probably involve some of the newer\n> discussions around this. I added some pointers to Mansi's proposal, and\n> perhaps that's something you should look into too. [2]\n>\n\nThat's a great point\nI will update this.\n\n> > *Objective 4: Sparse Topology & Boundary Awareness* +\n> > Modern Git workflows rely heavily on partial checkouts\n> > and submodules, and `repo info` should report these\n> > complex states natively.\n> > * *Implementation:* I will implement `layout.is-sparse`\n> >   to expose if the repository uses a sparse-checkout\n> >   cone, and `path.superproject-working-tree` to instantly\n> >   query if the current repository is a submodule.\n> >\n>\n> Those may be good additions.\n>\n> > == 4. PROJECT TIMELINE\n> >\n> > === 4.1 Community Bonding Period (May 1 - May 24)\n> >\n> > * Attend the Git community GSoC sessions to introduce\n> >   myself and establish a communication schedule.\n\n\n> >   resolution works correctly across POSIX and Windows\n> >   environments.\n>\n> I think this will take way more time than the two weeks allocated here,\n> mostly because of the design decisions we need finalize on.\n>\n\nI agree,\nI have actually changed a lot of my existing proposal\nI had a very hard time picking which project to leave out of scope\nsince I like all the projects equally\nBut I did double the allocated time in my existing proposal,\nI gave 4 weeks for paths and libification (Given that my above trail\nof thinking is correct it is just a small change i.e repo->worktree)\nI also gave 4 weeks for querying the prefixes\n\nGave a 3 weeks of buffer for path and libification and 2 weeks of\nbuffer for query.\n\n\n> > *Weeks 10 - 12 (July 27 - August 16):*\n> > * Implement the advanced topology and boundary keys\n> >   (`layout.is-sparse` and `path.superproject-working-tree`).\n> > * Run the full test suite and perform rigorous edge-case\n> >   testing ensuring libification does not cause\n> >   regressions.\n> > * Buffer period for addressing mailing list feedback\n> >   regarding the libification and sparse patches.\n> >\n>\n> Overall I think this is trying to do many things in a short time frame.\n> I would also consider the time it takes for reviews and iterations to\n> land.\n>\n\n\n\nI just wanted to say that the proposal I posted is in a new thread\nI understand making it inline is nice\nBut since a lot has changed\nI thought of adding it in a new thread to justify it [1]\n\n\nRegards,\n- Jayatheerth\n\n1 - https://lore.kernel.org/git/CA+rGoLd4ho5AmB3gWYP=yUUKJO=YqthxKX8R_rvN7V7exArn6Q@mail.gmail.com/T/#u\n"}]}