From: Karthik Nayak Date: Tue, 17 Mar 2026 09:37:45 GMT Subject: Re: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: In-Reply-To: Mansi Singh 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 > > == 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