> Hey everyone,
>
> This is my proposal for the project
> `Improve the new git repo command`.
>
> ---
> = GSoC 2026 PROPOSAL: IMPROVE THE NEW GIT REPO COMMAND
> Jayatheerth Kulkarni <jayatheerthkulkarni2005@gmail.com>
> v1.0, March 1, 2026
>
> == 1. ABOUT ME
>
> I am a junior at Geethanjali College of Engineering and
> Technology pursuing a bachelor's degree, with a strong
> interest in open-source projects and systems programming.
> My interest in the Git project stems from a desire to
> understand the internals of version control and contribute
> to a tool that is fundamental to the global software
> development ecosystem.
>
> === 1.1 Contact
> * Email: jayatheerthkulkarni2005@gmail.com
> * Website: https://jayatheerth.com/
> * GitHub: https://github.com/jayatheerthkulkarni
> * LinkedIn: https://www.linkedin.com/in/jayatheerth/
>
> === 1.2 Logistics
> * Timezone: Indian Standard Time (IST) / UTC+05:30
> * Tech Stack: C, Shell Scripting, Rust and Go
>
> == 2. CONTRIBUTION HISTORY
>
> I have formally completed all the prerequisites to apply
> for the GSoC "Improve the new git repo command" project.
> I have listed all of my work I have done in the past few
> months.
>
> === 2.1 Featured Contributions
>
> For many months, I have been actively engaging with the
> Git community through mailing list discussions and patch
> submissions. Notably, my work on fixing stash messaging
> behavior in submodule environments was featured in Git
> Rev-News edition 124.
>
> * [PATCH v3] stash: fix incorrect branch name in stash message*
>   Status: Merged into `master` & featured in Git Rev-News.
>   Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u
>
> === 2.2 Core Path and Submodule Patches
>
> * [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse*
>   Status: Merged into `master`.
>   Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u
>
> * [PATCH v2] dir: Fix and test wildcard pathspec handling*
>   Status: Merged into `master`.
>   Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/
>
> === 2.3 Refactoring and Micro-Projects
>
> I am deeply familiar with Git's test suite and standard
> C conventions, having submitted several refactoring and
> cleanup patches, including two specific to the
> `builtin/repo.c` file:
>
> * [PATCH GSoC] repo: Remove unnecessary variable shadow*
>   Status: Merged into `next`
>   Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t
>
> * [GSoC] t7101: modernize test path checks*
>   Status: Merged into `master` (Official micro-project).
>   Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t
>
> * [PATCH v2] pull: move options[] array into function scope*
>   Status: Merged to `master`.
>   Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u
>
> === 2.4 Documentation
>
> * [PATCH v3] Update MyFirstContribution.adoc to follow modern practices*
>   Status: Merged to `master`.
>   Link: https://lore.kernel.org/git/CA+rGoLfFVcUFctoEx6wshovGnRW8pTW--ZB42ntd01VHMJm_Rw@mail.gmail.com/T/#t
>
> === 2.5 Experience with C
>
> Since Git is mainly written in C, I have no issues
> navigating the codebase. I hold a Cisco CLP - Advanced C
> Programming certificate covering Unix and C systems
> programming, and I have completed two full university
> semesters of C programming.
>
> == 3. PROJECT PROPOSAL
>
> === 3.1 Why "Improve the new git repo command"?
>
> This project is compelling because I have closely followed
> its development since its inception in GSoC 2025.
> Consistently reading the weekly updates
> (https://lucasoshiro.github.io/gsoc-en/) and participating
> in the mailing list discussions has given me a deep
> understanding of the command's architecture.
> My previous work fixing cross-platform wildcard pathspecs
> in `dir.c` makes me uniquely suited to tackle the path
> resolution this project requires, while my C systems
> experience prepares me for the architectural refactoring
> of the command.
>
> === 3.2 Introduction
>
> The new `git repo info` command is positioned to be a
> cleaner, programmatic replacement for scraping
> `git rev-parse`. However, its current implementation lacks
> category-based querying, relies on global state macros,
> and is missing critical path data.
> To fully realize Git's libification effort and improve
> user experience, the internal architecture of
> `builtin/repo.c` must be modernized.
>
> === 3.3 Proposed Solution and Objectives
>
> Instead of just scraping basic paths, I propose an
> architectural update to `repo info`, safely utilizing the
> new `strbuf_add_path` API submitted by Lucas Oshiro.
>
> *Objective 1: Category-Based Query Architecture (The Core API)* +
> Currently, the `repo_info_fields` array relies on an
> exact-match binary search (`bsearch`). Users must request
> specific keys or use `--all`.
> I will rewrite the lookup logic to support
> category-prefix matching.
> * *Implementation:* I will implement an internal mapping
>   structure so that calling `git repo info path`
>   successfully identifies the category root and iterates
>   through all keys starting with `path.*`, returning them
>   dynamically.
>

> *Objective 2: Deep Libification (Removing Global State)* +
> The `builtin/repo.c` file is already highly modernized,
> but it opts into global state by declaring
> `USE_THE_REPOSITORY_VARIABLE` at the top of the file.
> * *Implementation:* I will remove this macro entirely.
>   The primary blocker in this file is `get_layout_bare()`,
>   which currently marks its local `repo` argument as
>   `UNUSED` and falls back to the global
>   `is_bare_repository()` helper.
>   I will refactor this function to drop the `UNUSED` tag
>   and explicitly evaluate the passed
>   `struct repository *repo` pointer.
>   I will thread this context down the call chain without
>   breaking existing external callers.
>

> *Objective 3: Core Path Resolution (`git rev-parse` parity)* +
> With the category API built, I will populate the `path.*`
> category by implementing the remaining path values currently
> obtained through `git rev-parse` and `--git-path`.
> Lucas Oshiro's recent patch series implemented `path.toplevel`;
> https://lore.kernel.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/T/#t
> I will build upon this foundation to implement the rest.
> Because path normalizations across different systems are
> complex, I will leverage my experience from `dir.c` to safely implement:
> * `path.git-dir`, `path.common-dir`, `path.worktree`.
> * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.
>

> *Objective 4: Sparse Topology & Boundary Awareness* +
> Modern Git workflows rely heavily on partial checkouts
> and submodules, and `repo info` should report these
> complex states natively.
> * *Implementation:* I will implement `layout.is-sparse`
>   to expose if the repository uses a sparse-checkout
>   cone, and `path.superproject-working-tree` to instantly
>   query if the current repository is a submodule.
>

> == 4. PROJECT TIMELINE
>
> === 4.1 Community Bonding Period (May 1 - May 24)
>
> * Attend the Git community GSoC sessions to introduce
>   myself and establish a communication schedule.
> * Initiate the design discussion on the mailing list
>   regarding the internal data structure for
>   Category-Based Queries.
> * Map out the exact C call chains affected by
>   `USE_THE_REPOSITORY_VARIABLE` in `builtin/repo.c`.
>
> === 4.2 Phase 1: Category Architecture & Core Paths
> (May 25 - July 5)
>
> *Weeks 1 - 3 (May 25 - June 14):*
> * Implement the category-based lookup mechanism in
>   `builtin/repo.c`.
> * Update the parsing logic so `git repo info <category>`
>   successfully returns all nested keys.
>
> *Weeks 4 - 6 (June 15 - July 5):*
> * Utilize Lucas's `strbuf_add_path` API to implement the
>   core path values.
> * Implement path related keys.
>   (`path.git-dir`, `path.common-dir`, `path.worktree`,
>    `path.objects`, `path.hooks`, `path.index`, and `path.grafts`)
> * Write rigorous OS-agnostic tests in `t/` to ensure path
>   resolution works correctly across POSIX and Windows
>   environments.

>
> === 4.3 Mid-Term Evaluation Phase (July 6 - July 10)
>
> * Ensure the category architecture and core paths are
>   merged into `master` or queued in `next`.
> * Review progress with mentors and adjust the Phase 2
>   timeline if necessary.
> * Submit mid-term evaluation.
>
> === 4.4 Phase 2: Removing Global State & Sparse Topology
> (July 11 - August 16)
>
> *Weeks 7 - 9 (July 11 - July 26):*
> * Focus entirely on libification.
> * Remove the `USE_THE_REPOSITORY_VARIABLE` macro from
>   `builtin/repo.c`.
> * Refactor `get_layout_bare()` and similar functions to
>   utilize the explicit `repo` parameter.
>
> *Weeks 10 - 12 (July 27 - August 16):*
> * Implement the advanced topology and boundary keys
>   (`layout.is-sparse` and `path.superproject-working-tree`).
> * Run the full test suite and perform rigorous edge-case
>   testing ensuring libification does not cause
>   regressions.
> * Buffer period for addressing mailing list feedback
>   regarding the libification and sparse patches.
>

> === 4.5 Finalization (August 17 - August 24)
>
> * Finalize the official Git documentation
>   (`Documentation/git-repo.txt`) for all new keys and
>   category querying.
> * Clean up the commit history and ensure all patches are
>   finalized on the mailing list.
> * Submit the final GSoC project report.
>
> === 4.6 Stretch Goals
>
> If review cycles move faster than anticipated, I will
> implement Split-Index Topology (`path.shared-index`)
> to report the path to the shared index file. I will
> also investigate natively parsing `git-sizer` metrics
> into the newly established category API to provide
> deeper repository health insights.
>
> == 5. AVAILABILITY AND BLOGGING
>
> This timeline aligns perfectly with my schedule.
> The project kicks off in May, during which I will be on
> summer vacation and can dedicate 35-50 hours a week.
> During June and July, I will transition into my final
> year of university.
> My academic schedule during this period is highly
> flexible.
>
> *Blogging:* +
> I have a domain setup at jayatheerth.com.
> As patches flow and the project progresses, I will host a
> dedicated endpoint at `/blogs` to provide comprehensive,
> weekly coverage of my project.
>
> == 6. POST GSOC COMMITMENT
>
> I actively follow the mailing list and intend to continue
> contributing bug fixes and enhancements.
> I have been a part of the Git community since 2025 and
> hopefully will continue to be one for a long time.
>
> --- End of proposal ---
>
> Regards
> - Jayatheerth