Re: [GSoC proposal v2][RFC] Improve the new git repo command

Since the last feedback from Lucas I have taken some time to improve my proposal

- I have added all my patches that I raised in Git.
- I have also taken up a much more realistic timeline.

---

Improve the new git repo command Jayatheerth Kulkarni February 26, 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

---

2. Contribution History

I have formally completed all the prerequisites to apply in 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
  Link: https://lore.kernel.org/git/20250611014204.24994-1-jayatheerthkulkarni2005@gmail.com/T/#u
  Status: Merged into master & featured in Git Rev-News.

2.2 Core Path and Submodule Patches

- [PATCH v8] submodule: prevent overwriting .gitmodules entry on path reuse
  Link: https://lore.kernel.org/git/20250608032705.11990-1-jayatheerthkulkarni2005@gmail.com/T/#u
  Status: Merged into master.

- [PATCH v2] dir: Fix and test wildcard pathspec handling
  Link: https://lore.kernel.org/git/20250422160547.577524-1-jayatheerthkulkarni2005@gmail.com/
  Status: Merged into master.

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
  Link: https://lore.kernel.org/git/aZxyju3B4NHp4c_t@denethor/T/#t
  Status: Got a review from Justin.

- [GSoC] t7101: modernize test path checks
  Link: https://lore.kernel.org/git/CALE2CrS0Q2NS1DbFv4pyRQsuypu=KH6Kurs=m4yWrFbR9QosoA@mail.gmail.com/T/#t
  Status: Merged into master (Official micro-project).

- [PATCH v2] pull: move options[] array into function scope
  Link: https://lore.kernel.org/git/20251212074433.38027-1-jayatheerthkulkarni2005@gmail.com/T/#u
  Status: Merged to master.

2.4 Documentation
I have also contributed to updating community guidelines:
- [PATCH v3] Update MyFirstContribution.adoc to follow modern practices
  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. Consistently reading the weekly updates (https://lucasoshiro.github.io/gsoc-en/) and following the mailing list patches for `git repo info` has deepened my ongoing interest in this specific initiative since GSoC 2025.

3.2 Introduction Taken from the SoC 2026 ideas page, the new `repo info` command has already started to be a good replacement for parts of `rev-parse`. As this command is still in its early stages, there is significant opportunity to refine its architecture and expand its feature set. Currently, many core functions in Git implicitly read environment variables and store them as global states. To support Git's ongoing "libification" effort, these global dependencies must be removed.

3.3 Proposed Solution and Objectives To ensure realistic pacing and to respect the rigorous nature of Git's mailing list review cycle, I have scoped the primary objectives of this project down to the two most critical milestones:

Objective 1: Adding Path Values
I will integrate the missing path values currently obtained through
`git rev-parse` and `--git-path`. This includes:
- `git-dir`, `common-dir`, `toplevel`, and `superproject-working-tree`.
- The grafts file, index file, objects directory, hooks directory, and
  `git-prefix`.
Implementation: I will take over the initial design efforts on the
mailing list, and finish the leftover work.

Objective 2: Removing Global State
The `builtin/repo.c` file currently opts into using global state by
declaring `#define USE_THE_REPOSITORY_VARIABLE`.
Implementation: I will remove this macro entirely. Functions that
currently implicitly rely on global state (e.g., `get_layout_bare()`,
which currently marks its `repo` argument as `UNUSED`) will be
refactored. I will update these functions to evaluate the explicit
`struct repository *repo` pointer, threading this context down the
call chain without breaking existing external callers.

---

4. Project Timeline

4.1 Community Bonding Period (May 1 - May 24)
- Attend the Git community GSoC sessions to introduce myself, the
  project, and establish a communication schedule with my mentors.
- Initiate the design discussion on the mailing list regarding the
  output format for path-related values (absolute vs. relative paths).
- Dive into existing efforts to map out exactly how resolves its current
  path outputs.

4.2 Phase 1: Core Path Implementation (May 25 - July 5)
Weeks 1 - 3 (May 25 - June 14): Foundation and Extended Path Values
- Implement the core path values (`git-dir`, `common-dir`, `toplevel`,
  and `superproject-working-tree`).
- Implement the remaining `--git-path` values.
- Write initial tests in `t/` to ensure path resolution works correctly.

Weeks 4 - 6 (June 15 - July 5): Review and Refinement
- Address mailing list feedback for the path values patch series.
- Begin mapping out the call chains affected by
  `USE_THE_REPOSITORY_VARIABLE` in preparation for Phase 2.

4.3 Mid-Term Evaluation Phase (July 6 - July 10)
- Ensure the path-related additions are merged into master or queued
  in the next.
- Review progress with mentors and adjust the Phase 2 timeline if
  necessary. Submit mid-term evaluation.

4.4 Phase 2: Removing Global State (July 11 - August 16)
Weeks 7 - 9 (July 11 - July 26): Threading the Context
- Focus entirely on libification. Remove the global state macro from
  `builtin/repo.c`.
- Refactor functions like `get_layout_bare()` to utilize the explicit
  `repo` parameter.
- Carefully audit and update external callers to use the new API context.

Weeks 10 - 12 (July 27 - August 16): Rigorous Testing and Iteration
- This period acts as a realistic buffer for the anticipated multiple
  versions required to get complex architectural refactoring merged.
- Run the full test suite and perform rigorous edge-case testing
  (e.g., sparse checkouts, nested submodules).

4.5 Finalization (August 17 - August 24)
- Finalize the official Git documentation for all new additions.
- Clean up the commit history, ensure all patches are finalized on
  the mailing list, and submit the final GSoC project report.

4.6 Stretch Goals
Given the rigorous nature of Git's patch review process, my primary
commitment is to successfully merge the core path additions and the
global state removal. However, if review cycles move faster than
anticipated, I have prepared the following stretch goals:
1. Category-Based Queries: Implementing an internal mapping structure
   so users can query by category (e.g., `git repo info paths`).
2. `repo structure` Enhancements: Analyzing the `git-sizer` codebase
   to integrate native repository metrics into `cmd_repo_structure()`.

---

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 full-time hours. 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