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

> 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