* [proposal][RFC] Improve the new git repo command
@ 2026-02-22 7:57 JAYATHEERTH K
2026-02-22 21:14 ` Lucas Seiki Oshiro
0 siblings, 1 reply; 4+ messages in thread
From: JAYATHEERTH K @ 2026-02-22 7:57 UTC (permalink / raw)
To: GIT Mailing-list
Cc: karthik nayak, Ayush Chandekar, jltobler, Siddharth Asthana,
Lucas Seiki Oshiro
Hi,
I am done with a rough draft of my proposal,
currently I am posting this in a text format but when I submit it officially
I am planning to make it a TeX pdf.
---
Improve the new git repo command
Jayatheerth Kulkarni
February 22, 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://linkedin.com/in/jayatheerth
1.2 Details related to projects:
Timezone: Indian Standard Time (IST) / UTC+05:30
My Tech Stack: C, Shell Scripting, Rust
---
2. Contribution History
2.1 Micro-Project (GSoC Requirement)
To familiarize myself with Git’s test suite and submission
guidelines, I completed the following micro-project:
Patch:
https://lore.kernel.org/git/20260109032027.68680-1-jayatheerthkulkarni2005@gmail.com/
[GSoC] t7101: modernize test path checks
Description: Replaced old-style test -[df] assertions with modern
test_path_is_* helpers in t7101-reset-empty-subdirs.sh. This
improves debuggability and aligns with modern Git coding standards.
I also addressed path reference inaccuracies in the test
descriptions.
Status: Merged into master.
2.1.1 A Micro-Patch to get started with repo.c codebase:
Patch:
https://lore.kernel.org/git/20260222004036.47744-1-jayatheerthkulkarni2005@gmail.com/T/#u
[GSoC] builtin/repo: remove unused hex.h header
Description: This is a micro-patch that simply removes an unused
header to demonstrate my familiarity with the repo.c codebase and
the mailing list submission process.
2.2 Taking part in the community
For many months, I have been a part of multiple discussions, one of
which even got featured in Git Rev-News edition 124.
https://git.github.io/rev_news/2025/06/30/edition-124/
A list of my past activities in Git:
July 2025
submodule: skip redundant active entries when pattern covers path
submodule: prevent overwriting .gitmodules on path reuse
Discussion link:
https://lore.kernel.org/git/CA+rGoLdTT3kdELUyHdZLWyy8e6AbfRU7kDFcVUdCmVtDi11hMw@mail.gmail.com/T/#m1e53511686dccdccab4a1c484703472e5e739c6c
Status: Merged into master
June 2025
stash: fix incorrect branch name in stash message
Discussion Link:
https://lore.kernel.org/git/f46443ac-eb7f-47db-8f4b-a06384e6fde5@web.de/T/#m4b9a4c0da4f35519b3eb98bdc3d1fce84efa80aa
Status: Merged into master and featured in Git Rev-News
(Discussions section)
These discussions highlight my ability to engage constructively
with the community and iterate on feedback.
2.3 Experience with C:
Since Git is mainly written in C, I would have no issues, as I am
well-versed in the language. I have received a Cisco CLP - Advanced
C Programming certificate, which covered Unix and C in good detail.
I have also taken two full semesters of C programming; therefore,
I can confidently understand existing C code in Git.
---
3. Project Proposal
3.1 Why "Improve the new git repo command"?
This project is particularly 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.
This continuous engagement has provided a strong understanding of
why the command exists and exactly what needs to be done.
3.2 Introduction
Taken from the SoC 2026 ideas page
(https://git.github.io/SoC-2026-Ideas/), the new repo info command
has already started to be a really 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.
Architectural Changes:
- Removing the global dependency on the_repository. This was a
project of its own in the past SoC 2025; now we implement this
in repo info.
- Currently, we can access either all repository info or we can
access info manually. Adding a feature where we can access things
by category (e.g., git repo info paths returning git-dir,
common-dir, and worktree, or git repo info core returning all
core-related configurations) would be a good change to this
command.
Feature Additions:
- Adding path-related values currently obtained through git
rev-parse (such as git-dir, common-dir, toplevel, and
superproject-working-tree).
- Adding more values currently obtained through git rev-parse
--git-path (such as the grafts file, index file, objects
directory, hooks directory, git-prefix, and other paths adjusted
by update_common_dir()).
3.3 Proposed Solution and Objectives
The main objective of this project is to implement the changes and
additions discussed in the introduction to make git repo a complete,
modern replacement for parts of rev-parse. My proposed solutions are:
- Removing the global state: The builtin/repo.c file currently opts
into using global state by declaring
#define USE_THE_REPOSITORY_VARIABLE at the top of the file. My
goal is to remove this macro entirely to align with Git's
libification efforts. To achieve this, I will refactor functions
that implicitly rely on this global state instead of the passed
repository context. For example, in get_layout_bare(), the repo
argument is currently marked as UNUSED because the function calls
is_bare_repository() (which checks global state). I will update
this and similar functions to evaluate the explicit repo struct
instead.
- Implementing category keys: I will add a way to map specific
categories to a group of values. For example, if a user types
git repo info paths, the internal logic will look up the paths
category and return git-dir, common-dir, and other related
values all at once instead of requiring manual queries for each.
- Adding path values: I will integrate the missing path values
currently obtained through git rev-parse (like toplevel and
superproject-working-tree) and --git-path (like index and hooks).
Since initial work on this has already started, my goal is to
take over the effort, lead the necessary design choices on the
mailing list, and complete the implementation.
- Enhancing repo structure: I will study the external git-sizer
tool to figure out which of its repository analysis and
statistics features can be natively implemented into the git
repo structure sub-command.
---
4. Project Timeline
From observing past GSoC proposal reviews, I understand that mailing
list discussions and patch iterations take time. I have structured
this timeline to be as realistic as possible, front-loading design
decisions and extending the schedule to accommodate standard review
cycles.
4.1 Community Bonding Period (May)
- 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, or adding an --absolute-paths flag). Getting consensus
early is critical so coding can begin in Week 2.
- Deep dive into path.c and setup.c to understand exactly how git
rev-parse currently resolves git-dir, common-dir, and --git-path
values.
4.2 Phase 1: Core Implementation (Weeks 2 - 6)
Weeks 2 and 3: Foundation and Extended Path Values
- Implement the core path values currently obtained via git
rev-parse: git-dir, common-dir, toplevel, and
superproject-working-tree.
- Implement the remaining values obtained via git rev-parse
--git-path: grafts file, index file, objects directory, hooks
directory, and git-prefix.
- Write initial tests in t/ to ensure path resolution works
correctly across standard, bare, and worktree setups, then
submit the first patch series.
Weeks 4 - 6: Removing Global State
- Focus entirely on libification. Remove
#define USE_THE_REPOSITORY_VARIABLE from builtin/repo.c.
- Refactor functions like get_layout_bare() that currently have an
UNUSED repo struct to evaluate the explicit repo parameter
instead of relying on global state.
- Run the full test suite to ensure dropping the global state macro
does not introduce regressions, and submit the patch series.
4.3 Mid-Term Evaluation Phase
- Ensure the path-related additions and the global state removal
patches are either merged into master or queued in next.
- Review progress with mentors, adjust the Phase 2 timeline based
on mailing list guidance, and submit the mid-term evaluation.
4.4 Phase 2: Categories and Structure Enhancements (Weeks 7 - 12)
Weeks 7 - 9: Category-Based Queries
- Implement the internal mapping structure to associate category
keys (e.g., paths, layout) with their respective individual keys.
- Modify the parsing logic in print_fields() and cmd_repo_info()
so that querying a category correctly loops through and outputs
the grouped values.
- Add documentation and tests for the new category arguments.
Submit patches for review.
Weeks 10 - 12: repo structure and git-sizer Integration
- Analyze the codebase of git-sizer and identify the most valuable,
easily integrated metrics (e.g., maximum tree depth, massive blob
detection) that fit natively into Git's C codebase.
- Implement these structural analysis additions into
cmd_repo_structure().
- Ensure the new metrics correctly output in both the table format
and the NUL-terminated/keyvalue formats.
4.5 Extended Period & Finalization (Weeks 13 - 14+)
Weeks 13 - 14: Buffer and Edge Cases
- This period acts as a realistic buffer for prolonged mailing list
discussions, particularly for the git-sizer integrations which
may require architectural feedback.
- Perform rigorous edge-case testing (e.g., running the new
commands inside sparse checkouts, nested submodules, and heavily
customized .git/config environments) and address final patch
revisions.
Final Week: Documentation and Handoff
- Finalize the official Git documentation for all new additions to
git repo info and git repo structure.
- Clean up the commit history, ensure all patches are finalized on
the mailing list, and submit the final GSoC project report.
---
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, allowing me to maintain a strong,
consistent level of activity and commit to the required hours.
Blogging:
I have a domain setup via Github pages at "jayatheerth.com" where
I host my portfolio site. As weekly patches flow and the project
progresses, I will host a dedicated endpoint at "/blogs" to provide
comprehensive, weekly coverage of everything that is going on with
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [proposal][RFC] Improve the new git repo command
2026-02-22 7:57 [proposal][RFC] Improve the new git repo command JAYATHEERTH K
@ 2026-02-22 21:14 ` Lucas Seiki Oshiro
2026-02-22 23:32 ` JAYATHEERTH K
2026-02-26 11:34 ` [GSoC proposal v2][RFC] " JAYATHEERTH K
0 siblings, 2 replies; 4+ messages in thread
From: Lucas Seiki Oshiro @ 2026-02-22 21:14 UTC (permalink / raw)
To: JAYATHEERTH K
Cc: GIT Mailing-list, karthik nayak, Ayush Chandekar, jltobler,
Siddharth Asthana
> A list of my past activities in Git:
Looking the Git history (`git log --author='K Jayatheerth'`), there
are many meaningful patches that you didn't listed here.
> 3. Project Proposal
>
> 3.1 Why "Improve the new git repo command"?
> This project is particularly 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.
> This continuous engagement has provided a strong understanding of
> why the command exists and exactly what needs to be done.
Thanks for your interest in my work :-).
> 3.3 Proposed Solution and Objectives
> The main objective of this project is to implement the changes and
> additions discussed in the introduction to make git repo a complete,
> modern replacement for parts of rev-parse. My proposed solutions are:
>
> - Removing the global state: The builtin/repo.c file currently opts
> into using global state by declaring
> #define USE_THE_REPOSITORY_VARIABLE at the top of the file. My
> goal is to remove this macro entirely to align with Git's
> libification efforts. To achieve this, I will refactor functions
> that implicitly rely on this global state instead of the passed
> repository context. For example, in get_layout_bare(), the repo
> argument is currently marked as UNUSED because the function calls
> is_bare_repository() (which checks global state). I will update
> this and similar functions to evaluate the explicit repo struct
> instead.
>
> - Implementing category keys: I will add a way to map specific
> categories to a group of values. For example, if a user types
> git repo info paths, the internal logic will look up the paths
> category and return git-dir, common-dir, and other related
> values all at once instead of requiring manual queries for each.
>
> - Adding path values: I will integrate the missing path values
> currently obtained through git rev-parse (like toplevel and
> superproject-working-tree) and --git-path (like index and hooks).
> Since initial work on this has already started, my goal is to
> take over the effort, lead the necessary design choices on the
> mailing list, and complete the implementation.
>
> - Enhancing repo structure: I will study the external git-sizer
> tool to figure out which of its repository analysis and
> statistics features can be natively implemented into the git
> repo structure sub-command.
It looks to me that you're proposing too much here. I mean, I agree
with everything that you proposed here, but maybe you won't have
enough time to do that given the pace of the reviewing process. For
example, my first GSoC patch series took 11 versions until it was
accepted.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [proposal][RFC] Improve the new git repo command
2026-02-22 21:14 ` Lucas Seiki Oshiro
@ 2026-02-22 23:32 ` JAYATHEERTH K
2026-02-26 11:34 ` [GSoC proposal v2][RFC] " JAYATHEERTH K
1 sibling, 0 replies; 4+ messages in thread
From: JAYATHEERTH K @ 2026-02-22 23:32 UTC (permalink / raw)
To: Lucas Seiki Oshiro
Cc: GIT Mailing-list, karthik nayak, Ayush Chandekar, jltobler,
Siddharth Asthana
Hey Lucas,
Thanks for taking time to review my proposal
On Mon, Feb 23, 2026 at 2:44 AM Lucas Seiki Oshiro
<lucasseikioshiro@gmail•com> wrote:
>
>
> > A list of my past activities in Git:
>
> Looking the Git history (`git log --author='K Jayatheerth'`), there
> are many meaningful patches that you didn't listed here.
>
I agree, I think adding
https://github.com/git/git/commit/ec727e189cce9e8457e2b00e0756cfdf325a12d9
Would make sense too because that patch is path related
But the others are doc changes, do you suggest I add those too?
>
> It looks to me that you're proposing too much here. I mean, I agree
> with everything that you proposed here, but maybe you won't have
> enough time to do that given the pace of the reviewing process. For
> example, my first GSoC patch series took 11 versions until it was
> accepted.
>
Alright, this is tough because to me everything seems equally important
Since you started this command, can you probably point out to me which
of these in proposals are
needed urgently? as in which of these are high impact, and do you
suggest I remove the other parts?
Regards
- Jayatheerth
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [GSoC proposal v2][RFC] Improve the new git repo command
2026-02-22 21:14 ` Lucas Seiki Oshiro
2026-02-22 23:32 ` JAYATHEERTH K
@ 2026-02-26 11:34 ` JAYATHEERTH K
1 sibling, 0 replies; 4+ messages in thread
From: JAYATHEERTH K @ 2026-02-26 11:34 UTC (permalink / raw)
To: Lucas Seiki Oshiro
Cc: GIT Mailing-list, karthik nayak, Ayush Chandekar, Justin Tobler,
Siddharth Asthana
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-02-26 11:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-22 7:57 [proposal][RFC] Improve the new git repo command JAYATHEERTH K
2026-02-22 21:14 ` Lucas Seiki Oshiro
2026-02-22 23:32 ` JAYATHEERTH K
2026-02-26 11:34 ` [GSoC proposal v2][RFC] " JAYATHEERTH K
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox