{"thread":{"id":"65097","subject":"[GSoC][PROPOSAL] Improving and Extending the git repo command","startedAt":"2026-02-28T16:50:12Z","lastAt":"2026-03-01T06:14:08Z","messageCount":3,"participants":["Ayush Jha","Lucas Seiki Oshiro"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537396","messageId":"CAFNBzOc=tuph7ecqt9TAY-aCWUkPyQ84DYjwMp3QS4-0J-wF_Q@mail.gmail.com","threadId":"65097","inReplyTo":null,"subject":"[GSoC][PROPOSAL] Improving and Extending the git repo command","fromName":"Ayush Jha","fromEmail":"kumarayushjha123@gmail.com","sentAt":"2026-02-28T16:49:59Z","receivedAt":"2026-02-28T16:50:12Z","isPatch":false,"sender":{"key":"kumarayushjha123@gmail.com","avatar":null},"body":"Hi everyone,\n\nI'm Ayush Kumar Jha, a 4th-year student at SVNIT, India. I've been\ncontributing to Git for the last couple of months, mostly focusing on\nreducing global state dependencies. I've really enjoyed the process of\ngetting to know the codebase and the community, and I'm very\ninterested in participating in GSoC 2026.\n\nI've put together a draft proposal for the \"Improve the new git repo\ncommand\" project. Based on my recent work trying to libify parts of\nthe configuration state, I feel this project aligns well with what\nI've been trying to learn about Git's architecture.\n\nI would be incredibly grateful for any feedback you might have. In\nparticular, I'd love to know if my planned milestones seem realistic,\nor if there are specific path metadata keys or git-sizer stats that\nthe community feels are more important to prioritize.\n\nThanks in advance for your time!\n\nBest regards,\nAyush\n\n----------------------------------------------------------------------\n\nGSoC 2026 Proposal: Improving and Extending the git repo command\n\n1. Personal Information\nName: Ayush Kumar Jha\nEmail: kumarayushjha123@gmail.com\nGitHub: https://github.com/ayush-jha123\nEducation: SVNIT, India (4th Year B.Tech in ECE)\nTimezone: IST (UTC+5:30)\n\n----------------------------------------------------------------------\n2. Project Abstract\nGit's traditional reliance on global state (like the_repository) makes\nit difficult to use as a library or manage multiple repositories in a\nsingle process. The git repo command, introduced recently, is an\nexcellent step toward a clean, programmatic interface for repository\nmetadata.\n\nHowever, as an initial implementation, it still relies on some global\nstate under the hood and is missing a lot of path-related data that\nusers currently have to scrape from `git rev-parse`. Also, the\n`structure` subcommand currently counts objects but has room for much\ndeeper health analytics.\n\nMy goal for the summer is to:\n* Finish decoupling builtin/repo.c from the_repository.\n* Consolidate scattered path information (git-dir, hooks, objects,\netc.) into `git repo info`.\n* Port helpful repository health metrics (like tree depth and large\nobject detection from tools like git-sizer) into `git repo structure`\nusing the new path-walk API.\n\n----------------------------------------------------------------------\n3. Current Contributions\nMy recent contributions have been centered around the libification\neffort, which helped me get familiar with the areas of the codebase\nthis project touches:\n\n* [RFC GSoC PATCH v3 1/2] repo-settings: add repo_settings_get_is_bare\n  Link: https://lore.kernel.org/git/20260208075905.1807-1-kumarayushjha123@gmail.com/\n  Status: Superseded (Proof of Concept for libification)\n  Description: The existing is_bare_repository() helper relies on the\nglobal the_repository variable. I introduced a lazily evaluated\nis_bare field inside struct repository_settings and exposed it through\na new accessor function. This allows call sites to determine bareness\nusing an explicit repository context.\n\n* [RFC GSoC PATCH v3 2/2] attr: use local repository state in read_attr\n  Link: https://lore.kernel.org/git/20260208075905.1807-1-kumarayushjha123@gmail.com/T/#t\n  Status: Superseded (Explored safe modification of core structures)\n  Description: I refactored read_attr() to determine bareness using\nthe repository associated with istate->repo instead of the global\nhelper.\n  Remarks: This series went through three iterations (v1-v3) based on\ngreat feedback from the community. Though it was ultimately superseded\nby a concurrent, broader architectural redesign by other contributors,\nthe exercise gave me deep familiarity with Git's configuration flow\nand how to safely modify core structures.\n\n* [RFC GSoC PATCH] environment: move trust_ctime to repo_settings\n  Link: https://lore.kernel.org/git/CAFNBzOdqOLKFbDFCp99GvXYWs_Af3PdeXQMjE92y+s92j78GYA@mail.gmail.com/T/#t\n  Status: Dropped (Yielded to ongoing concurrent series)\n  Description: Proposed moving core.trustctime to a\nrepository-specific structure. During review, maintainers noted\noverlap with an active series migrating configuration handling to\nrepo_config_values. I dropped the patch to avoid duplicating effort\nand to respect the ongoing work.\n\n* doc: fix typo in tree-walk.h comment\n  Link: https://lore.kernel.org/git/20260205080853.2034-1-kumarayushjha123@gmail.com/\n  Status: Under Review\n  Description: Corrected a duplicate word in tree-walk.h.\n  Remarks: This was my first patch to get comfortable with the Git\nmailing list workflow.\n\n----------------------------------------------------------------------\n4. Technical Plan\n\nA. Decoupling from Global State\nCurrently, builtin/repo.c uses USE_THE_REPOSITORY_VARIABLE. For\nexample, get_layout_bare() calls the global is_bare_repository().\nI plan to refactor builtin/repo.c to strictly use the struct\nrepository *repo argument passed down from git.c, replacing global\nhelpers with repository-scoped equivalents.\nI am aware that related architectural improvements in this area are\nbeing discussed and developed by other contributors. I will ensure my\nwork aligns with the direction agreed upon by maintainers and will be\nhappy to build on or adapt to those changes as needed.\n\nB. Enhancing git repo info\nI want to eliminate the need for users to scrape `git rev-parse` flags\nto find paths. Building upon the foundational ideas discussed on the\nmailing list and in branches like Lucas Oshiro's `repo-info-path`\n(https://github.com/lucasoshiro/git/compare/master...repo-info-path/),\nI will implement category-based querying (e.g., `git repo info\nlayout`).\nNew keys to implement:\n* path.git-dir\n* path.common-dir\n* path.hooks\n* path.objects\n* path.toplevel\nNote to reviewers: I'd like to hear your thoughts on whether these\npaths should default to relative or absolute. My initial thought is\nrelative by default with an `--absolute` flag, as that seems to match\nuser expectations for CLI tools like `git rev-parse`.\n\nC. Enhancing git repo structure\nI want to add metrics inspired by `github/git-sizer` to help users\nassess repository health:\n* Maximum tree depth.\n* Identification of exceptionally large blobs (with a configurable\nbyte threshold).\nI plan to implement this using the new path-walk API for fast,\nefficient traversal instead of slower rev-list approaches.\n\n----------------------------------------------------------------------\n5. Timeline\n\n* Community Bonding (May 1 - May 26)\n  Discuss the path schema (e.g., paths.* vs layout.paths.*) and\nrelative/absolute defaults on the list. Finalize the exact git-sizer\nmetrics we want to port over.\n\n* Phase 1: Libification & Metadata (May 27 - July 11)\n  Weeks 1-2: Remove the_repository from builtin/repo.c. Standardize\nthe use of the `repo` argument.\n  Weeks 3-4: Implement category-based key filtering.\n  Weeks 5-7: Implement path-related keys (git-dir, common-dir,\ntoplevel, hooks, objects) and write tests in t/.\n\n* Phase 2: Advanced Structure Analysis (July 12 - Aug 18)\n  Weeks 8-9: Integrate the path-walk API into cmd_repo_structure.\n  Weeks 10-11: Implement tree depth counters and large object detection.\n  Week 12: Buffer for fixing OS-specific path normalization issues and\nfine-tuning performance.\n\n* Wrap up (Aug 19 - Aug 26)\n  Final documentation cleanup, polishing, and submitting the final report.\n\n----------------------------------------------------------------------\n6. Risks & Mitigations\n\n* Path Normalization: Reporting paths correctly across Windows and\nLinux can be tricky. I will rely on normalize_path_copy() and ensure\nthe test suite adequately covers edge cases on Windows environments.\n* Performance: Adding heavy checks to `structure` could slow it down.\nUtilizing path-walk mitigates this greatly, but I will also ensure\nthese checks are fast enough on large repos (like linux.git) or place\nthe deepest analytics behind an `--expensive` flag if necessary.\n\n----------------------------------------------------------------------\n7. Availability\nI can commit 35-40 hours a week to this project over the summer. I\nplan to be highly active on the mailing list and IRC for reviews and\ndiscussions.\n\n----------------------------------------------------------------------\n8. Resources & References\nTo ensure my proposal aligns with the community's vision, I have been\nstudying the following resources:\n* Original discussion on `git repo info`:\n  https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u\n* Lucas Oshiro's exploratory branch for path metadata:\n  https://github.com/lucasoshiro/git/compare/master...repo-info-path/\n* The `github/git-sizer` repository for identifying ideal health metrics.\n* Official documentation for `git-repo(1)` and `git-rev-parse(1)`.\n"},{"id":"537416","messageId":"B8697AB9-9C9B-41C9-A2D8-1848CD966137@gmail.com","threadId":"65097","inReplyTo":"CAFNBzOc=tuph7ecqt9TAY-aCWUkPyQ84DYjwMp3QS4-0J-wF_Q@mail.gmail.com","subject":"Re: [GSoC][PROPOSAL] Improving and Extending the git repo command","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2026-02-28T22:58:32Z","receivedAt":"2026-02-28T22:58:48Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> Hi everyone,\n\nHi, Ayush!\n\n> Note to reviewers: I'd like to hear your thoughts on whether these\n> paths should default to relative or absolute. My initial thought is\n> relative by default with an `--absolute` flag, as that seems to match\n> user expectations for CLI tools like `git rev-parse`.\n\nI've just sent the path (trying to) add support for paths (the one\nyou mentioned). I don't know if it's the best approach. I CC'ed you\nand the other GSoC applicants that are interested in git-repo-info.\n\nI wouldn't say that the user's expectations is to retrieve absolute\npaths by default, we need to check each one of the \"options for\nfiles\" modified by --path-format and see what makes more sense.\nSee [1].\n\n[1] fac60b8925 (rev-parse: add option for absolute or relative path formatting, 2020-12-13)\n"},{"id":"537428","messageId":"CAFNBzOe8_GbXFTmL5UuLWa+5xa=D04jJkmqMumerajeYGkVwaA@mail.gmail.com","threadId":"65097","inReplyTo":"B8697AB9-9C9B-41C9-A2D8-1848CD966137@gmail.com","subject":"Re: [GSoC][PROPOSAL] Improving and Extending the git repo command","fromName":"Ayush Jha","fromEmail":"kumarayushjha123@gmail.com","sentAt":"2026-03-01T06:13:56Z","receivedAt":"2026-03-01T06:14:08Z","isPatch":false,"sender":{"key":"kumarayushjha123@gmail.com","avatar":null},"body":"Hi Lucas,\n\nThank you for this feedback and for pointing out commit fac60b8925!\n\nYou are completely right—assuming a blanket \"relative by default\"\nexpectation ignores the historical nuance of how git rev-parse handles\ndifferent path options. I have updated my proposal draft to remove\nthat assumption and properly acknowledge the complexity of path\nformatting for repo-info.\n\nI also just left my thoughts on your new repo-info --path-format patch\nseries addressing this exact issue over on that thread! Let me know if\nthat direction seems correct.\n\n(Also, apologies if my reply to that patch series looks a bit strange\nin your inbox—I accidentally put Jayatheerth in the 'To' field and you\nin 'CC' when replying!)\n\nThanks again for the guidance,\nAyush\n\nOn Sun, Mar 1, 2026 at 4:28 AM Lucas Seiki Oshiro\n<lucasseikioshiro@gmail.com> wrote:\n>\n>\n> > Hi everyone,\n>\n> Hi, Ayush!\n>\n> > Note to reviewers: I'd like to hear your thoughts on whether these\n> > paths should default to relative or absolute. My initial thought is\n> > relative by default with an `--absolute` flag, as that seems to match\n> > user expectations for CLI tools like `git rev-parse`.\n>\n> I've just sent the path (trying to) add support for paths (the one\n> you mentioned). I don't know if it's the best approach. I CC'ed you\n> and the other GSoC applicants that are interested in git-repo-info.\n>\n> I wouldn't say that the user's expectations is to retrieve absolute\n> paths by default, we need to check each one of the \"options for\n> files\" modified by --path-format and see what makes more sense.\n> See [1].\n>\n> [1] fac60b8925 (rev-parse: add option for absolute or relative path formatting, 2020-12-13)\n"}]}