[GSoC][PROPOSAL] Improve the new git repo command

[GSoC][PROPOSAL] Improve the new git repo command

[JAYATHEERTH K]

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

[GSoC][PROPOSAL] Improve the new git repo command

[Mansi Singh]

Hi everyone,

I am Mansi Singh, an M.S. student at Northeastern University Seattle.
I would like to share my proposal for the "Improve the new git repo
command" project under GSoC 2026. I would appreciate any feedback.

---

GSoC 2026 Proposal: Improve the new git repo command
Mansi Singh <mansimaanu8627@gmail.com>

== 1. PERSONAL INFORMATION

* Name: Mansi Singh
* Email: mansimaanu8627@gmail.com
* GitHub: https://github.com/MansiSingh17
* Education: M.S. Information Systems, Northeastern University Seattle,
  GPA 4.0, Expected May 2027
* Timezone: PST (UTC-8)
* Availability: 40 hours/week, May through August 2026

== 2. ABOUT ME

I have 3+ years of professional software development experience, most
recently at Nokia Solutions and Networks where I built AI-powered
monitoring tools for engineering teams. Before that, at Grant Thornton,
I built distributed audit automation platforms processing data across
thousands of projects. This background in building analytics and
diagnostics tools gives me direct context for why repository health
metrics matter to developers at scale.

== 3. CONTRIBUTIONS TO GIT

=== 3.1 Microproject: t7605 - Replace test -f with test_path_is_file

Replaced old-style path checks with modern test helpers in
t/t7605-merge-resolve.sh. Went through 3 review iterations responding
to feedback from Lucas Seiki Oshiro and name consistency feedback from
Junio C Hamano. The patch was integrated into seen.

  PR: https://github.com/gitgitgadget/git/pull/2050

=== 3.2 repo: Remove redundant variable shadow in
        stats_table_print_structure

In stats_table_print_structure() inside builtin/repo.c, the variable
'entry' was declared at the top of the loop body and then redeclared
identically inside an if block. Removed the inner redeclaration.

  PR: https://github.com/gitgitgadget/git/pull/2062

=== 3.3 t1900: Add tests for git repo structure subcommand

The t1900 test file had no tests for git repo structure at all. Added
4 tests covering the default, keyvalue, and nul output formats, plus
rejection of an unknown format.

  PR: https://github.com/gitgitgadget/git/pull/2064

== 4. PROJECT DESCRIPTION

=== 4.1 Scope Decision

After reading Kaartic Sivaraam's reply on March 10 advising applicants
that the repo info scope was under discussion and suggesting looking at
other areas, I examined the full project landscape carefully.

The path-related git repo info work is already well underway — eslam
reda's patch series is at v6 and actively being reviewed. At the same
time, the ideas page explicitly lists git repo structure enhancements
("functionality from git-sizer could be added to provide more detailed
repository analysis") but nobody has started implementing them. That
is the gap I am proposing to fill.

=== 4.2 The Gap: git repo structure vs git-sizer

git repo structure currently reports reference counts, object counts
by type, and inflated/disk sizes. Comparing against git-sizer reveals
three entire sections that are missing:

Missing: Biggest objects
  - objects.commits.max-size
  - objects.commits.max-parents
  - objects.trees.max-entries
  - objects.blobs.max-size

Missing: History structure
  - history.max-depth
  - history.max-tag-depth

Missing: Biggest checkout metrics
  - checkout.max-directories
  - checkout.max-path-depth
  - checkout.max-path-length
  - checkout.max-files
  - checkout.symlinks

== 5. TECHNICAL PLAN

=== 5.1 Phase 1: Biggest Objects Metrics

Extend the count_objects() callback in builtin/repo.c to track maximum
values in addition to totals. Add corresponding fields to struct
object_stats and struct object_values. Extend both table and keyvalue
output formatters.

=== 5.2 Phase 2: History Structure Metrics

Implement maximum history depth using topological traversal with
memoization. Discuss performance trade-offs on the mailing list before
implementing. For repositories like linux.git these traversals can be
expensive, so I will place them behind --expensive if needed.

=== 5.3 Phase 3: Biggest Checkout Metrics

Use the existing path-walk API (walk_objects_by_path) already called
in cmd_repo_structure(). Extend the path_fn callback to track tree
entry counts and path lengths during traversal.

=== 5.4 Phase 4: Removing Global State (Stretch Goal)

builtin/repo.c uses USE_THE_REPOSITORY_VARIABLE. The most visible
instance is get_layout_bare() which marks its repo argument as UNUSED
and calls the global is_bare_repository() instead. I will implement
this as a stretch goal, coordinating with the ongoing libification
work in the community to avoid duplicating effort.

== 6. TIMELINE

Community Bonding (May 1 - May 26):
  - Establish sync schedule with mentors
  - Initiate mailing list discussion on metric naming and priority
  - Study git-sizer implementation for algorithmic approaches
  - Finalize struct extensions needed

Phase 1: Biggest Objects (Weeks 1-4, May 27 - Jun 22):
  - Weeks 1-2: Extend structs, update count_objects() callback
  - Week 3: Extend formatters, write tests in t1900-repo-structure.sh
  - Week 4: Address review feedback

Phase 2: History Structure (Weeks 5-7, Jun 23 - Jul 12):
  - Week 5: Implement commit graph traversal for max-depth
  - Week 6: Implement max-tag-depth, add output and tests
  - Week 7: Midterm buffer, address feedback

Midterm goal: Phase 1 merged or in next. Phase 2 under review.

Phase 3: Biggest Checkouts (Weeks 8-10, Jul 15 - Aug 2):
  - Weeks 8-9: Extend path-walk callback
  - Week 10: Output formatters, tests, documentation

Weeks 11-12: Buffer and Finalization (Aug 3 - Aug 17):
  - Address remaining review feedback
  - Begin Phase 4 if time permits
  - Final documentation and GSoC report

== 7. RISKS AND MITIGATIONS

Review cycles: Structured so Phase 1 completes early, giving maximum
time for iterations before midterm.

Performance: Will benchmark history traversal against linux.git and
use --expensive flag if needed.

Design disagreements: Will initiate naming and format discussions
during bonding period before writing any code.

== 8. WHY I AM THE RIGHT PERSON

The git repo structure enhancements I am proposing are fundamentally
a repository analytics problem. At Nokia I built monitoring tools that
aggregate diagnostic metrics for engineering teams. At Grant Thornton
I built systems analyzing data across thousands of projects.

I have already studied builtin/repo.c, run both subcommands, identified
the gaps by comparing against git-sizer, and made three contributions
touching the repo codebase directly — including tests specifically for
git repo structure, which is the subcommand I am proposing to enhance.

My microproject went through 3 review iterations in under 2 weeks and
was integrated into seen.

== 9. REFERENCES

* GSoC 2026 ideas page: https://git.github.io/SoC-2026-Ideas/
* git-sizer: https://github.com/github/git-sizer
* Original git repo introduction:
  https://lore.kernel.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/
* Microproject PR: https://github.com/gitgitgadget/git/pull/2050
* Variable shadow fix: https://github.com/gitgitgadget/git/pull/2062
* Structure tests: https://github.com/gitgitgadget/git/pull/2064

Regards,
Mansi

Re: [GSoC][PROPOSAL] Improve the new git repo command

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 8756 bytes --]

Mansi Singh <mansimaanu8627@gmail.com> writes:

> Hi everyone,
>
> I am Mansi Singh, an M.S. student at Northeastern University Seattle.
> I would like to share my proposal for the "Improve the new git repo
> command" project under GSoC 2026. I would appreciate any feedback.
>
> ---
>
> GSoC 2026 Proposal: Improve the new git repo command
> Mansi Singh <mansimaanu8627@gmail.com>
>
> == 1. PERSONAL INFORMATION
>
> * Name: Mansi Singh
> * Email: mansimaanu8627@gmail.com
> * GitHub: https://github.com/MansiSingh17
> * Education: M.S. Information Systems, Northeastern University Seattle,
>   GPA 4.0, Expected May 2027
> * Timezone: PST (UTC-8)
> * Availability: 40 hours/week, May through August 2026
>
> == 2. ABOUT ME
>
> I have 3+ years of professional software development experience, most
> recently at Nokia Solutions and Networks where I built AI-powered
> monitoring tools for engineering teams. Before that, at Grant Thornton,
> I built distributed audit automation platforms processing data across
> thousands of projects. This background in building analytics and
> diagnostics tools gives me direct context for why repository health
> metrics matter to developers at scale.
>
> == 3. CONTRIBUTIONS TO GIT
>
> === 3.1 Microproject: t7605 - Replace test -f with test_path_is_file
>
> Replaced old-style path checks with modern test helpers in
> t/t7605-merge-resolve.sh. Went through 3 review iterations responding
> to feedback from Lucas Seiki Oshiro and name consistency feedback from
> Junio C Hamano. The patch was integrated into seen.
>
>   PR: https://github.com/gitgitgadget/git/pull/2050
>
> === 3.2 repo: Remove redundant variable shadow in
>         stats_table_print_structure
>
> In stats_table_print_structure() inside builtin/repo.c, the variable
> 'entry' was declared at the top of the loop body and then redeclared
> identically inside an if block. Removed the inner redeclaration.
>
>   PR: https://github.com/gitgitgadget/git/pull/2062
>
> === 3.3 t1900: Add tests for git repo structure subcommand
>
> The t1900 test file had no tests for git repo structure at all. Added
> 4 tests covering the default, keyvalue, and nul output formats, plus
> rejection of an unknown format.
>
>   PR: https://github.com/gitgitgadget/git/pull/2064
>
> == 4. PROJECT DESCRIPTION
>
> === 4.1 Scope Decision
>
> After reading Kaartic Sivaraam's reply on March 10 advising applicants
> that the repo info scope was under discussion and suggesting looking at
> other areas, I examined the full project landscape carefully.
>
> The path-related git repo info work is already well underway — eslam
> reda's patch series is at v6 and actively being reviewed. At the same
> time, the ideas page explicitly lists git repo structure enhancements
> ("functionality from git-sizer could be added to provide more detailed
> repository analysis") but nobody has started implementing them. That
> is the gap I am proposing to fill.
>

I would contest this a bit. There was overlapping work between what
Lucas was doing [1] and eslam was [2]. Neither of them have been picked
up by the maintainer.

I still think this needs to be done. But before approaching the problem
with a solution, we need to see some discussion around relative vs
absolute paths and how to go about it. Brian shed some light on it [3],
but there was no concrete solution as such.

This is not to say your proposal doesn't make sense. It is totally valid
to make a proposal to fill in the gap between `git repo structure` and
`git sizer` as you have.

> === 4.2 The Gap: git repo structure vs git-sizer
>
> git repo structure currently reports reference counts, object counts
> by type, and inflated/disk sizes. Comparing against git-sizer reveals
> three entire sections that are missing:
>
> Missing: Biggest objects
>   - objects.commits.max-size
>   - objects.commits.max-parents
>   - objects.trees.max-entries
>   - objects.blobs.max-size
>
> Missing: History structure
>   - history.max-depth
>   - history.max-tag-depth
>
> Missing: Biggest checkout metrics
>   - checkout.max-directories
>   - checkout.max-path-depth
>   - checkout.max-path-length
>   - checkout.max-files
>   - checkout.symlinks
>

There was also discussion about adding buckets to the metrics and
providing Histograms [4].

> == 5. TECHNICAL PLAN
>
> === 5.1 Phase 1: Biggest Objects Metrics
>
> Extend the count_objects() callback in builtin/repo.c to track maximum
> values in addition to totals. Add corresponding fields to struct
> object_stats and struct object_values. Extend both table and keyvalue
> output formatters.
>
> === 5.2 Phase 2: History Structure Metrics
>
> Implement maximum history depth using topological traversal with
> memoization. Discuss performance trade-offs on the mailing list before
> implementing. For repositories like linux.git these traversals can be
> expensive, so I will place them behind --expensive if needed.
>
> === 5.3 Phase 3: Biggest Checkout Metrics
>
> Use the existing path-walk API (walk_objects_by_path) already called
> in cmd_repo_structure(). Extend the path_fn callback to track tree
> entry counts and path lengths during traversal.
>
> === 5.4 Phase 4: Removing Global State (Stretch Goal)
>
> builtin/repo.c uses USE_THE_REPOSITORY_VARIABLE. The most visible
> instance is get_layout_bare() which marks its repo argument as UNUSED
> and calls the global is_bare_repository() instead. I will implement
> this as a stretch goal, coordinating with the ongoing libification
> work in the community to avoid duplicating effort.
>
> == 6. TIMELINE
>
> Community Bonding (May 1 - May 26):
>   - Establish sync schedule with mentors
>   - Initiate mailing list discussion on metric naming and priority
>   - Study git-sizer implementation for algorithmic approaches
>   - Finalize struct extensions needed
>
> Phase 1: Biggest Objects (Weeks 1-4, May 27 - Jun 22):
>   - Weeks 1-2: Extend structs, update count_objects() callback
>   - Week 3: Extend formatters, write tests in t1900-repo-structure.sh
>   - Week 4: Address review feedback
>
> Phase 2: History Structure (Weeks 5-7, Jun 23 - Jul 12):
>   - Week 5: Implement commit graph traversal for max-depth
>   - Week 6: Implement max-tag-depth, add output and tests
>   - Week 7: Midterm buffer, address feedback
>
> Midterm goal: Phase 1 merged or in next. Phase 2 under review.
>
> Phase 3: Biggest Checkouts (Weeks 8-10, Jul 15 - Aug 2):
>   - Weeks 8-9: Extend path-walk callback
>   - Week 10: Output formatters, tests, documentation
>
> Weeks 11-12: Buffer and Finalization (Aug 3 - Aug 17):
>   - Address remaining review feedback
>   - Begin Phase 4 if time permits
>   - Final documentation and GSoC report
>
> == 7. RISKS AND MITIGATIONS
>
> Review cycles: Structured so Phase 1 completes early, giving maximum
> time for iterations before midterm.
>
> Performance: Will benchmark history traversal against linux.git and
> use --expensive flag if needed.
>
> Design disagreements: Will initiate naming and format discussions
> during bonding period before writing any code.
>
> == 8. WHY I AM THE RIGHT PERSON
>
> The git repo structure enhancements I am proposing are fundamentally
> a repository analytics problem. At Nokia I built monitoring tools that
> aggregate diagnostic metrics for engineering teams. At Grant Thornton
> I built systems analyzing data across thousands of projects.
>
> I have already studied builtin/repo.c, run both subcommands, identified
> the gaps by comparing against git-sizer, and made three contributions
> touching the repo codebase directly — including tests specifically for
> git repo structure, which is the subcommand I am proposing to enhance.
>
> My microproject went through 3 review iterations in under 2 weeks and
> was integrated into seen.
>
> == 9. REFERENCES
>
> * GSoC 2026 ideas page: https://git.github.io/SoC-2026-Ideas/
> * git-sizer: https://github.com/github/git-sizer
> * Original git repo introduction:
>   https://lore.kernel.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/
> * Microproject PR: https://github.com/gitgitgadget/git/pull/2050
> * Variable shadow fix: https://github.com/gitgitgadget/git/pull/2062
> * Structure tests: https://github.com/gitgitgadget/git/pull/2064
>
> Regards,
> Mansi

The rest looks good to me :)

Regards,
Karthik

[1]: 20260228224252.72788-1-lucasseikioshiro@gmail.com
[2]: pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com
[3]: aaSusXil9nDHYGMR@fruit.crustytoothpaste.net
[4]: CA+rGoLd0_gc36EBv_DieVqtjLn1FL39vtT5ib1fEbk-+OvPP6A@mail.gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: [GSoC][PROPOSAL] Improve the new git repo command

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 12159 bytes --]

JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com> writes:

Hello,

> 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.
>

This would definitely be nice to have. Have you also thought about glob
pattern matching too? That way a user could do

  $ git repo info "path*"

And have it list all keys which start with path. Similar to how you plan
to do category matching, but this can also do

  $ git repo info "*object*"

So any keys with object in it would match too. Either ways I'm just
thinking out loud and not saying this is what you _should_ do.

> *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.
>

It would be nice to collate some of the efforts already made in this
direction, I know its not as simple [1] as passing in the repo since
`is_bare_repository()` has a lot of callees.

> *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`.
>

This is the crux, but you should also probably involve some of the newer
discussions around this. I added some pointers to Mansi's proposal, and
perhaps that's something you should look into too. [2]

> *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.
>

Those may be good additions.

> == 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.

I think this will take way more time than the two weeks allocated here,
mostly because of the design decisions we need finalize on.

>
> === 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.
>

Overall I think this is trying to do many things in a short time frame.
I would also consider the time it takes for reviews and iterations to
land.

> === 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

Regards,
Karthik

[1]: https://lore.kernel.org/git/xmqqbji0b5ak.fsf@gitster.g/#t
[2]: CAOLa=ZTtNSZ904v0-SN16jAis7gK4=MVj1g_5CGdbmaBopeZkg@mail.gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: [GSoC][PROPOSAL] Improve the new git repo command

[K Jayatheerth]

Hey Karthik,

Thank you for taking time to go through the proposal.


> > * *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.
> >
>
> This would definitely be nice to have. Have you also thought about glob
> pattern matching too? That way a user could do
>
>   $ git repo info "path*"
>
> And have it list all keys which start with path. Similar to how you plan
> to do category matching, but this can also do
>
>   $ git repo info "*object*"
>
> So any keys with object in it would match too. Either ways I'm just
> thinking out loud and not saying this is what you _should_ do.
>

I hadn't thought about globbing till now
but I have now given it a thought, I personally believe we don't need
globs (at least not now)

There are hardly 4 elements in the array `repo_info_field` as of now
even if we add all the paths I think it will not go beyond 20 elements.
And I think globbing is a problem we would have to debate after we get
to >= 30 elements,
globbing has its advantages, it gets insanely flexible but I don't
believe it is a current problem.
I could however add an RFC in the community bonding period.


> >   and explicitly evaluate the passed
> >   `struct repository *repo` pointer.
> >   I will thread this context down the call chain without
> >   breaking existing external callers.
> >
>
> It would be nice to collate some of the efforts already made in this
> direction, I know its not as simple [1] as passing in the repo since
> `is_bare_repository()` has a lot of callees.
>

After posting this proposal
I was tweaking around and found out repo->worktree
It holding a `NULL` value is directly supposed to indicate it is
`bare` if I am correct?

I maybe wrong here
But writing up a quick change where

static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)
{
strbuf_addstr(buf, is_bare_repository() ? "true" : "false");
return 0;
}

becomes

static int get_layout_bare(struct repository *repo, struct strbuf *buf)
{
strbuf_addstr(buf, (repo->worktree == NULL) ? "true" : "false");
return 0;
}

and removing the macro
#define USE_THE_REPOSITORY_VARIABLE

would work is what I have dug so far
I would of course not send a patch until GSoC starts
But I wanted to know if I am thinking in the right direction here?


> > * `path.git-dir`, `path.common-dir`, `path.worktree`.
> > * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.
> >
>
> This is the crux, but you should also probably involve some of the newer
> discussions around this. I added some pointers to Mansi's proposal, and
> perhaps that's something you should look into too. [2]
>

That's a great point
I will update this.

> > *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.
> >
>
> Those may be good additions.
>
> > == 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.


> >   resolution works correctly across POSIX and Windows
> >   environments.
>
> I think this will take way more time than the two weeks allocated here,
> mostly because of the design decisions we need finalize on.
>

I agree,
I have actually changed a lot of my existing proposal
I had a very hard time picking which project to leave out of scope
since I like all the projects equally
But I did double the allocated time in my existing proposal,
I gave 4 weeks for paths and libification (Given that my above trail
of thinking is correct it is just a small change i.e repo->worktree)
I also gave 4 weeks for querying the prefixes

Gave a 3 weeks of buffer for path and libification and 2 weeks of
buffer for query.


> > *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.
> >
>
> Overall I think this is trying to do many things in a short time frame.
> I would also consider the time it takes for reviews and iterations to
> land.
>



I just wanted to say that the proposal I posted is in a new thread
I understand making it inline is nice
But since a lot has changed
I thought of adding it in a new thread to justify it [1]


Regards,
- Jayatheerth

1 - https://lore.kernel.org/git/CA+rGoLd4ho5AmB3gWYP=yUUKJO=YqthxKX8R_rvN7V7exArn6Q@mail.gmail.com/T/#u

[GSoC][PROPOSAL] Improve the new git repo command

[jayesh0104]

Hi all,

I am Jayesh Daga, a third-year Computer Science undergraduate at VIT Chennai.
I would like to submit my proposal for the GSoC 2026 project: "Improve the new git repo command".
I would greatly appreciate feedback from the community and mentors.

---

== 1. Personal Information

Name: Jayesh Daga
Email: jayeshdaga99@gmail.com
GitHub: https://github.com/jayesh0104
University: Vellore Institute of Technology, India
Timezone: IST (UTC+5:30)
Availability: 35–40 hours/week (May–August 2026)

---

== 2. About Me

I am a systems-oriented developer with a strong interest in developer tools,
version control systems, and backend infrastructure.

I have experience in C, C++, Python, and JavaScript, and have worked on:
- real-time telemetry systems
- CI/CD pipelines
- backend services

I enjoy working close to system internals, where small design decisions
can significantly impact usability and performance.

---

== 3. Contributions to Git

I have actively contributed to the Git project, particularly in improving
test consistency and aligning with Git’s internal testing framework.

- Replaced raw file checks with `test_path_is_missing` to align with
  Git’s testing conventions
- Fixed incorrect helper usage that could lead to test failures

One of my patches has been integrated into the `next` branch of Git,
indicating that it has passed initial review and integration stages.

I have participated in the full upstream contribution workflow:
- Sending patches via git-send-email
- Engaging in mailing list discussions
- Responding to maintainer feedback
- Submitting revised versions (v2, v3)

For example, after feedback from a Git contributor, I identified a mismatch
between the commit message and the actual code change and submitted a
corrected v3 patch.

Through this process, I gained a strong understanding of:
- Git’s test framework and helper utilities
- The importance of precise commit messages
- Incremental patch-based development and review cycles

---

== 4. Project Overview

The `git repo` command is a recent addition intended to provide a
structured interface for querying repository metadata and structure.

However, it currently:
- lacks coverage for many commonly used values
- has limited structure in output
- does not yet serve as a unified abstraction over existing commands

This project aims to evolve `git repo` into a complete, consistent,
and script-friendly interface for repository introspection.

---

== 5. Problem Statement

Currently, repository metadata is fragmented across multiple commands:

- `git rev-parse` → paths and repository state
- `git config` → configuration
- external tools like git-sizer → repository metrics

This results in:
- fragmentation (multiple commands required)
- inconsistent output formats
- lack of a unified abstraction

The `git repo` command is intended to address this, but remains incomplete.

---

== 6. Technical Proposal

The implementation will primarily involve extending logic in
`builtin/repo.c`, reusing existing helpers used by commands like
`rev-parse`, and ensuring consistency with Git’s internal APIs.

### 6.1 Path Metadata Expansion

Add support for:

Core paths:
- paths.git_dir
- paths.common_dir
- paths.toplevel
- paths.superproject_working_tree

Git-path equivalents:
- paths.objects
- paths.index
- paths.hooks
- paths.grafts
- paths.prefix

Design:
- Default to relative paths (portable)
- Optional `--absolute` flag

Final decisions will be made through mailing list discussion.

---

### 6.2 Structured Output

Current output is flat key-value.

Proposed:

{
  "paths": { ... },
  "layout": { ... }
}

Benefits:
- easier machine parsing
- better extensibility
- clearer organization

Backward compatibility will be preserved.

---

### 6.3 Remove Global State

Replace usage of global `the_repository` with explicit:

    struct repository *repo

Benefits:
- improved modularity
- better testability
- future extensibility

---

### 6.4 Extend `git repo structure`

Add metrics inspired by git-sizer:
- object counts
- largest blobs
- tree depth

Ensure:
- incremental additions
- performance safety

---

### 6.5 Testing and Documentation

Testing:
- extend tests in `t/`
- cover edge cases (bare repos, worktrees, submodules)

Documentation:
- update `git-repo.txt`
- include examples and usage patterns

---

== 7. Timeline

Community Bonding:
- study relevant code (`builtin/repo.c`, `repository.c`, `setup.c`)
- initiate mailing list discussions (paths, structure)
- submit small patch

Weeks 1–2:
- implement core path metadata
- testing and review

Weeks 3–4:
- implement git-path equivalents
- ensure parity with rev-parse

Weeks 5–6:
- refactor global state usage
- submit incremental patches

Weeks 7–8:
- structured output implementation
- RFC discussion and iteration

Weeks 9–10:
- extend repo structure metrics
- validate performance

Weeks 11–12:
- polishing, documentation, final review

---

== 8. Risks and Mitigation

Design disagreements:
- addressed via early RFC discussions

Performance concerns:
- benchmark before merging
- optional flags for expensive operations

Review delays:
- mitigated through small, incremental patches

---

== 9. Why Me

I have already contributed to Git and worked through its mailing list
development workflow.

Having a patch integrated into the `next` branch and iterating through
v2 and v3 revisions has given me practical experience with Git’s
expectations around correctness, clarity, and incremental changes.

My background in systems programming allows me to reason about API design,
performance trade-offs, and maintainability—key aspects of this project.

---

== 10. Future Work

I intend to continue contributing to Git beyond GSoC, particularly in:
- stabilizing `git repo` as a porcelain command
- improving developer-facing tooling

---

Thank you for your time and consideration. I would greatly appreciate
any feedback on this proposal.

Thanks,
Jayesh Daga