# [GSoC][PROPOSAL] Improve the new git repo command 2 messages from 2026-03-14 to 2026-03-17. Participants: Mansi Singh, Karthik Nayak. Thread: https://gitlist.dev/t/65242 ## Mansi Singh, 2026-03-14 02:54 Subject: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: URL: https://gitlist.dev/e/CAO_P5U3g_%2BRpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ%40mail.gmail.com ``` 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. === 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 ``` ## Karthik Nayak, 2026-03-17 09:37 Subject: Re: [GSoC][PROPOSAL] Improve the new git repo command Message-ID: URL: https://gitlist.dev/e/CAOLa%3DZTtNSZ904v0-SN16jAis7gK4%3DMVj1g_5CGdbmaBopeZkg%40mail.gmail.com 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 ```