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

Mansi Singh <mansimaanu8627@gmail.com> writes:

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.

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

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