{"thread":{"id":"65242","subject":"[GSoC][PROPOSAL] Improve the new git repo command","startedAt":"2026-03-14T02:54:45Z","lastAt":"2026-03-17T09:37:49Z","messageCount":2,"participants":["Mansi Singh","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"538947","messageId":"CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com","threadId":"65242","inReplyTo":null,"subject":"[GSoC][PROPOSAL] Improve the new git repo command","fromName":"Mansi Singh","fromEmail":"mansimaanu8627@gmail.com","sentAt":"2026-03-14T02:54:32Z","receivedAt":"2026-03-14T02:54:45Z","isPatch":false,"sender":{"key":"mansimaanu8627@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40687671?v=4"},"body":"Hi everyone,\n\nI am Mansi Singh, an M.S. student at Northeastern University Seattle.\nI would like to share my proposal for the \"Improve the new git repo\ncommand\" project under GSoC 2026. I would appreciate any feedback.\n\n---\n\nGSoC 2026 Proposal: Improve the new git repo command\nMansi Singh <mansimaanu8627@gmail.com>\n\n== 1. PERSONAL INFORMATION\n\n* Name: Mansi Singh\n* Email: mansimaanu8627@gmail.com\n* GitHub: https://github.com/MansiSingh17\n* Education: M.S. Information Systems, Northeastern University Seattle,\n  GPA 4.0, Expected May 2027\n* Timezone: PST (UTC-8)\n* Availability: 40 hours/week, May through August 2026\n\n== 2. ABOUT ME\n\nI have 3+ years of professional software development experience, most\nrecently at Nokia Solutions and Networks where I built AI-powered\nmonitoring tools for engineering teams. Before that, at Grant Thornton,\nI built distributed audit automation platforms processing data across\nthousands of projects. This background in building analytics and\ndiagnostics tools gives me direct context for why repository health\nmetrics matter to developers at scale.\n\n== 3. CONTRIBUTIONS TO GIT\n\n=== 3.1 Microproject: t7605 - Replace test -f with test_path_is_file\n\nReplaced old-style path checks with modern test helpers in\nt/t7605-merge-resolve.sh. Went through 3 review iterations responding\nto feedback from Lucas Seiki Oshiro and name consistency feedback from\nJunio C Hamano. The patch was integrated into seen.\n\n  PR: https://github.com/gitgitgadget/git/pull/2050\n\n=== 3.2 repo: Remove redundant variable shadow in\n        stats_table_print_structure\n\nIn stats_table_print_structure() inside builtin/repo.c, the variable\n'entry' was declared at the top of the loop body and then redeclared\nidentically inside an if block. Removed the inner redeclaration.\n\n  PR: https://github.com/gitgitgadget/git/pull/2062\n\n=== 3.3 t1900: Add tests for git repo structure subcommand\n\nThe t1900 test file had no tests for git repo structure at all. Added\n4 tests covering the default, keyvalue, and nul output formats, plus\nrejection of an unknown format.\n\n  PR: https://github.com/gitgitgadget/git/pull/2064\n\n== 4. PROJECT DESCRIPTION\n\n=== 4.1 Scope Decision\n\nAfter reading Kaartic Sivaraam's reply on March 10 advising applicants\nthat the repo info scope was under discussion and suggesting looking at\nother areas, I examined the full project landscape carefully.\n\nThe path-related git repo info work is already well underway — eslam\nreda's patch series is at v6 and actively being reviewed. At the same\ntime, the ideas page explicitly lists git repo structure enhancements\n(\"functionality from git-sizer could be added to provide more detailed\nrepository analysis\") but nobody has started implementing them. That\nis the gap I am proposing to fill.\n\n=== 4.2 The Gap: git repo structure vs git-sizer\n\ngit repo structure currently reports reference counts, object counts\nby type, and inflated/disk sizes. Comparing against git-sizer reveals\nthree entire sections that are missing:\n\nMissing: Biggest objects\n  - objects.commits.max-size\n  - objects.commits.max-parents\n  - objects.trees.max-entries\n  - objects.blobs.max-size\n\nMissing: History structure\n  - history.max-depth\n  - history.max-tag-depth\n\nMissing: Biggest checkout metrics\n  - checkout.max-directories\n  - checkout.max-path-depth\n  - checkout.max-path-length\n  - checkout.max-files\n  - checkout.symlinks\n\n== 5. TECHNICAL PLAN\n\n=== 5.1 Phase 1: Biggest Objects Metrics\n\nExtend the count_objects() callback in builtin/repo.c to track maximum\nvalues in addition to totals. Add corresponding fields to struct\nobject_stats and struct object_values. Extend both table and keyvalue\noutput formatters.\n\n=== 5.2 Phase 2: History Structure Metrics\n\nImplement maximum history depth using topological traversal with\nmemoization. Discuss performance trade-offs on the mailing list before\nimplementing. For repositories like linux.git these traversals can be\nexpensive, so I will place them behind --expensive if needed.\n\n=== 5.3 Phase 3: Biggest Checkout Metrics\n\nUse the existing path-walk API (walk_objects_by_path) already called\nin cmd_repo_structure(). Extend the path_fn callback to track tree\nentry counts and path lengths during traversal.\n\n=== 5.4 Phase 4: Removing Global State (Stretch Goal)\n\nbuiltin/repo.c uses USE_THE_REPOSITORY_VARIABLE. The most visible\ninstance is get_layout_bare() which marks its repo argument as UNUSED\nand calls the global is_bare_repository() instead. I will implement\nthis as a stretch goal, coordinating with the ongoing libification\nwork in the community to avoid duplicating effort.\n\n== 6. TIMELINE\n\nCommunity Bonding (May 1 - May 26):\n  - Establish sync schedule with mentors\n  - Initiate mailing list discussion on metric naming and priority\n  - Study git-sizer implementation for algorithmic approaches\n  - Finalize struct extensions needed\n\nPhase 1: Biggest Objects (Weeks 1-4, May 27 - Jun 22):\n  - Weeks 1-2: Extend structs, update count_objects() callback\n  - Week 3: Extend formatters, write tests in t1900-repo-structure.sh\n  - Week 4: Address review feedback\n\nPhase 2: History Structure (Weeks 5-7, Jun 23 - Jul 12):\n  - Week 5: Implement commit graph traversal for max-depth\n  - Week 6: Implement max-tag-depth, add output and tests\n  - Week 7: Midterm buffer, address feedback\n\nMidterm goal: Phase 1 merged or in next. Phase 2 under review.\n\nPhase 3: Biggest Checkouts (Weeks 8-10, Jul 15 - Aug 2):\n  - Weeks 8-9: Extend path-walk callback\n  - Week 10: Output formatters, tests, documentation\n\nWeeks 11-12: Buffer and Finalization (Aug 3 - Aug 17):\n  - Address remaining review feedback\n  - Begin Phase 4 if time permits\n  - Final documentation and GSoC report\n\n== 7. RISKS AND MITIGATIONS\n\nReview cycles: Structured so Phase 1 completes early, giving maximum\ntime for iterations before midterm.\n\nPerformance: Will benchmark history traversal against linux.git and\nuse --expensive flag if needed.\n\nDesign disagreements: Will initiate naming and format discussions\nduring bonding period before writing any code.\n\n== 8. WHY I AM THE RIGHT PERSON\n\nThe git repo structure enhancements I am proposing are fundamentally\na repository analytics problem. At Nokia I built monitoring tools that\naggregate diagnostic metrics for engineering teams. At Grant Thornton\nI built systems analyzing data across thousands of projects.\n\nI have already studied builtin/repo.c, run both subcommands, identified\nthe gaps by comparing against git-sizer, and made three contributions\ntouching the repo codebase directly — including tests specifically for\ngit repo structure, which is the subcommand I am proposing to enhance.\n\nMy microproject went through 3 review iterations in under 2 weeks and\nwas integrated into seen.\n\n== 9. REFERENCES\n\n* GSoC 2026 ideas page: https://git.github.io/SoC-2026-Ideas/\n* git-sizer: https://github.com/github/git-sizer\n* Original git repo introduction:\n  https://lore.kernel.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/\n* Microproject PR: https://github.com/gitgitgadget/git/pull/2050\n* Variable shadow fix: https://github.com/gitgitgadget/git/pull/2062\n* Structure tests: https://github.com/gitgitgadget/git/pull/2064\n\nRegards,\nMansi\n"},{"id":"539207","messageId":"CAOLa=ZTtNSZ904v0-SN16jAis7gK4=MVj1g_5CGdbmaBopeZkg@mail.gmail.com","threadId":"65242","inReplyTo":"CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL] Improve the new git repo command","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-03-17T09:37:45Z","receivedAt":"2026-03-17T09:37:49Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Mansi Singh <mansimaanu8627@gmail.com> writes:\n\n> Hi everyone,\n>\n> I am Mansi Singh, an M.S. student at Northeastern University Seattle.\n> I would like to share my proposal for the \"Improve the new git repo\n> command\" project under GSoC 2026. I would appreciate any feedback.\n>\n> ---\n>\n> GSoC 2026 Proposal: Improve the new git repo command\n> Mansi Singh <mansimaanu8627@gmail.com>\n>\n> == 1. PERSONAL INFORMATION\n>\n> * Name: Mansi Singh\n> * Email: mansimaanu8627@gmail.com\n> * GitHub: https://github.com/MansiSingh17\n> * Education: M.S. Information Systems, Northeastern University Seattle,\n>   GPA 4.0, Expected May 2027\n> * Timezone: PST (UTC-8)\n> * Availability: 40 hours/week, May through August 2026\n>\n> == 2. ABOUT ME\n>\n> I have 3+ years of professional software development experience, most\n> recently at Nokia Solutions and Networks where I built AI-powered\n> monitoring tools for engineering teams. Before that, at Grant Thornton,\n> I built distributed audit automation platforms processing data across\n> thousands of projects. This background in building analytics and\n> diagnostics tools gives me direct context for why repository health\n> metrics matter to developers at scale.\n>\n> == 3. CONTRIBUTIONS TO GIT\n>\n> === 3.1 Microproject: t7605 - Replace test -f with test_path_is_file\n>\n> Replaced old-style path checks with modern test helpers in\n> t/t7605-merge-resolve.sh. Went through 3 review iterations responding\n> to feedback from Lucas Seiki Oshiro and name consistency feedback from\n> Junio C Hamano. The patch was integrated into seen.\n>\n>   PR: https://github.com/gitgitgadget/git/pull/2050\n>\n> === 3.2 repo: Remove redundant variable shadow in\n>         stats_table_print_structure\n>\n> In stats_table_print_structure() inside builtin/repo.c, the variable\n> 'entry' was declared at the top of the loop body and then redeclared\n> identically inside an if block. Removed the inner redeclaration.\n>\n>   PR: https://github.com/gitgitgadget/git/pull/2062\n>\n> === 3.3 t1900: Add tests for git repo structure subcommand\n>\n> The t1900 test file had no tests for git repo structure at all. Added\n> 4 tests covering the default, keyvalue, and nul output formats, plus\n> rejection of an unknown format.\n>\n>   PR: https://github.com/gitgitgadget/git/pull/2064\n>\n> == 4. PROJECT DESCRIPTION\n>\n> === 4.1 Scope Decision\n>\n> After reading Kaartic Sivaraam's reply on March 10 advising applicants\n> that the repo info scope was under discussion and suggesting looking at\n> other areas, I examined the full project landscape carefully.\n>\n> The path-related git repo info work is already well underway — eslam\n> reda's patch series is at v6 and actively being reviewed. At the same\n> time, the ideas page explicitly lists git repo structure enhancements\n> (\"functionality from git-sizer could be added to provide more detailed\n> repository analysis\") but nobody has started implementing them. That\n> is the gap I am proposing to fill.\n>\n\nI would contest this a bit. There was overlapping work between what\nLucas was doing [1] and eslam was [2]. Neither of them have been picked\nup by the maintainer.\n\nI still think this needs to be done. But before approaching the problem\nwith a solution, we need to see some discussion around relative vs\nabsolute paths and how to go about it. Brian shed some light on it [3],\nbut there was no concrete solution as such.\n\nThis is not to say your proposal doesn't make sense. It is totally valid\nto make a proposal to fill in the gap between `git repo structure` and\n`git sizer` as you have.\n\n> === 4.2 The Gap: git repo structure vs git-sizer\n>\n> git repo structure currently reports reference counts, object counts\n> by type, and inflated/disk sizes. Comparing against git-sizer reveals\n> three entire sections that are missing:\n>\n> Missing: Biggest objects\n>   - objects.commits.max-size\n>   - objects.commits.max-parents\n>   - objects.trees.max-entries\n>   - objects.blobs.max-size\n>\n> Missing: History structure\n>   - history.max-depth\n>   - history.max-tag-depth\n>\n> Missing: Biggest checkout metrics\n>   - checkout.max-directories\n>   - checkout.max-path-depth\n>   - checkout.max-path-length\n>   - checkout.max-files\n>   - checkout.symlinks\n>\n\nThere was also discussion about adding buckets to the metrics and\nproviding Histograms [4].\n\n> == 5. TECHNICAL PLAN\n>\n> === 5.1 Phase 1: Biggest Objects Metrics\n>\n> Extend the count_objects() callback in builtin/repo.c to track maximum\n> values in addition to totals. Add corresponding fields to struct\n> object_stats and struct object_values. Extend both table and keyvalue\n> output formatters.\n>\n> === 5.2 Phase 2: History Structure Metrics\n>\n> Implement maximum history depth using topological traversal with\n> memoization. Discuss performance trade-offs on the mailing list before\n> implementing. For repositories like linux.git these traversals can be\n> expensive, so I will place them behind --expensive if needed.\n>\n> === 5.3 Phase 3: Biggest Checkout Metrics\n>\n> Use the existing path-walk API (walk_objects_by_path) already called\n> in cmd_repo_structure(). Extend the path_fn callback to track tree\n> entry counts and path lengths during traversal.\n>\n> === 5.4 Phase 4: Removing Global State (Stretch Goal)\n>\n> builtin/repo.c uses USE_THE_REPOSITORY_VARIABLE. The most visible\n> instance is get_layout_bare() which marks its repo argument as UNUSED\n> and calls the global is_bare_repository() instead. I will implement\n> this as a stretch goal, coordinating with the ongoing libification\n> work in the community to avoid duplicating effort.\n>\n> == 6. TIMELINE\n>\n> Community Bonding (May 1 - May 26):\n>   - Establish sync schedule with mentors\n>   - Initiate mailing list discussion on metric naming and priority\n>   - Study git-sizer implementation for algorithmic approaches\n>   - Finalize struct extensions needed\n>\n> Phase 1: Biggest Objects (Weeks 1-4, May 27 - Jun 22):\n>   - Weeks 1-2: Extend structs, update count_objects() callback\n>   - Week 3: Extend formatters, write tests in t1900-repo-structure.sh\n>   - Week 4: Address review feedback\n>\n> Phase 2: History Structure (Weeks 5-7, Jun 23 - Jul 12):\n>   - Week 5: Implement commit graph traversal for max-depth\n>   - Week 6: Implement max-tag-depth, add output and tests\n>   - Week 7: Midterm buffer, address feedback\n>\n> Midterm goal: Phase 1 merged or in next. Phase 2 under review.\n>\n> Phase 3: Biggest Checkouts (Weeks 8-10, Jul 15 - Aug 2):\n>   - Weeks 8-9: Extend path-walk callback\n>   - Week 10: Output formatters, tests, documentation\n>\n> Weeks 11-12: Buffer and Finalization (Aug 3 - Aug 17):\n>   - Address remaining review feedback\n>   - Begin Phase 4 if time permits\n>   - Final documentation and GSoC report\n>\n> == 7. RISKS AND MITIGATIONS\n>\n> Review cycles: Structured so Phase 1 completes early, giving maximum\n> time for iterations before midterm.\n>\n> Performance: Will benchmark history traversal against linux.git and\n> use --expensive flag if needed.\n>\n> Design disagreements: Will initiate naming and format discussions\n> during bonding period before writing any code.\n>\n> == 8. WHY I AM THE RIGHT PERSON\n>\n> The git repo structure enhancements I am proposing are fundamentally\n> a repository analytics problem. At Nokia I built monitoring tools that\n> aggregate diagnostic metrics for engineering teams. At Grant Thornton\n> I built systems analyzing data across thousands of projects.\n>\n> I have already studied builtin/repo.c, run both subcommands, identified\n> the gaps by comparing against git-sizer, and made three contributions\n> touching the repo codebase directly — including tests specifically for\n> git repo structure, which is the subcommand I am proposing to enhance.\n>\n> My microproject went through 3 review iterations in under 2 weeks and\n> was integrated into seen.\n>\n> == 9. REFERENCES\n>\n> * GSoC 2026 ideas page: https://git.github.io/SoC-2026-Ideas/\n> * git-sizer: https://github.com/github/git-sizer\n> * Original git repo introduction:\n>   https://lore.kernel.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/\n> * Microproject PR: https://github.com/gitgitgadget/git/pull/2050\n> * Variable shadow fix: https://github.com/gitgitgadget/git/pull/2062\n> * Structure tests: https://github.com/gitgitgadget/git/pull/2064\n>\n> Regards,\n> Mansi\n\nThe rest looks good to me :)\n\nRegards,\nKarthik\n\n[1]: 20260228224252.72788-1-lucasseikioshiro@gmail.com\n[2]: pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com\n[3]: aaSusXil9nDHYGMR@fruit.crustytoothpaste.net\n[4]: CA+rGoLd0_gc36EBv_DieVqtjLn1FL39vtT5ib1fEbk-+OvPP6A@mail.gmail.com\n"}]}