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