# [GSoC][PROPOSAL] Improving and Extending the git repo command 3 messages from 2026-02-28 to 2026-03-01. Participants: Ayush Jha, Lucas Seiki Oshiro. Thread: https://gitlist.dev/t/65097 ## Ayush Jha, 2026-02-28 16:49 Subject: [GSoC][PROPOSAL] Improving and Extending the git repo command Message-ID: URL: https://gitlist.dev/e/CAFNBzOc%3Dtuph7ecqt9TAY-aCWUkPyQ84DYjwMp3QS4-0J-wF_Q%40mail.gmail.com ``` Hi everyone, I'm Ayush Kumar Jha, a 4th-year student at SVNIT, India. I've been contributing to Git for the last couple of months, mostly focusing on reducing global state dependencies. I've really enjoyed the process of getting to know the codebase and the community, and I'm very interested in participating in GSoC 2026. I've put together a draft proposal for the "Improve the new git repo command" project. Based on my recent work trying to libify parts of the configuration state, I feel this project aligns well with what I've been trying to learn about Git's architecture. I would be incredibly grateful for any feedback you might have. In particular, I'd love to know if my planned milestones seem realistic, or if there are specific path metadata keys or git-sizer stats that the community feels are more important to prioritize. Thanks in advance for your time! Best regards, Ayush ---------------------------------------------------------------------- GSoC 2026 Proposal: Improving and Extending the git repo command 1. Personal Information Name: Ayush Kumar Jha Email: kumarayushjha123@gmail.com GitHub: https://github.com/ayush-jha123 Education: SVNIT, India (4th Year B.Tech in ECE) Timezone: IST (UTC+5:30) ---------------------------------------------------------------------- 2. Project Abstract Git's traditional reliance on global state (like the_repository) makes it difficult to use as a library or manage multiple repositories in a single process. The git repo command, introduced recently, is an excellent step toward a clean, programmatic interface for repository metadata. However, as an initial implementation, it still relies on some global state under the hood and is missing a lot of path-related data that users currently have to scrape from `git rev-parse`. Also, the `structure` subcommand currently counts objects but has room for much deeper health analytics. My goal for the summer is to: * Finish decoupling builtin/repo.c from the_repository. * Consolidate scattered path information (git-dir, hooks, objects, etc.) into `git repo info`. * Port helpful repository health metrics (like tree depth and large object detection from tools like git-sizer) into `git repo structure` using the new path-walk API. ---------------------------------------------------------------------- 3. Current Contributions My recent contributions have been centered around the libification effort, which helped me get familiar with the areas of the codebase this project touches: * [RFC GSoC PATCH v3 1/2] repo-settings: add repo_settings_get_is_bare Link: https://lore.kernel.org/git/20260208075905.1807-1-kumarayushjha123@gmail.com/ Status: Superseded (Proof of Concept for libification) Description: The existing is_bare_repository() helper relies on the global the_repository variable. I introduced a lazily evaluated is_bare field inside struct repository_settings and exposed it through a new accessor function. This allows call sites to determine bareness using an explicit repository context. * [RFC GSoC PATCH v3 2/2] attr: use local repository state in read_attr Link: https://lore.kernel.org/git/20260208075905.1807-1-kumarayushjha123@gmail.com/T/#t Status: Superseded (Explored safe modification of core structures) Description: I refactored read_attr() to determine bareness using the repository associated with istate->repo instead of the global helper. Remarks: This series went through three iterations (v1-v3) based on great feedback from the community. Though it was ultimately superseded by a concurrent, broader architectural redesign by other contributors, the exercise gave me deep familiarity with Git's configuration flow and how to safely modify core structures. * [RFC GSoC PATCH] environment: move trust_ctime to repo_settings Link: https://lore.kernel.org/git/CAFNBzOdqOLKFbDFCp99GvXYWs_Af3PdeXQMjE92y+s92j78GYA@mail.gmail.com/T/#t Status: Dropped (Yielded to ongoing concurrent series) Description: Proposed moving core.trustctime to a repository-specific structure. During review, maintainers noted overlap with an active series migrating configuration handling to repo_config_values. I dropped the patch to avoid duplicating effort and to respect the ongoing work. * doc: fix typo in tree-walk.h comment Link: https://lore.kernel.org/git/20260205080853.2034-1-kumarayushjha123@gmail.com/ Status: Under Review Description: Corrected a duplicate word in tree-walk.h. Remarks: This was my first patch to get comfortable with the Git mailing list workflow. ---------------------------------------------------------------------- 4. Technical Plan A. Decoupling from Global State Currently, builtin/repo.c uses USE_THE_REPOSITORY_VARIABLE. For example, get_layout_bare() calls the global is_bare_repository(). I plan to refactor builtin/repo.c to strictly use the struct repository *repo argument passed down from git.c, replacing global helpers with repository-scoped equivalents. I am aware that related architectural improvements in this area are being discussed and developed by other contributors. I will ensure my work aligns with the direction agreed upon by maintainers and will be happy to build on or adapt to those changes as needed. B. Enhancing git repo info I want to eliminate the need for users to scrape `git rev-parse` flags to find paths. Building upon the foundational ideas discussed on the mailing list and in branches like Lucas Oshiro's `repo-info-path` (https://github.com/lucasoshiro/git/compare/master...repo-info-path/), I will implement category-based querying (e.g., `git repo info layout`). New keys to implement: * path.git-dir * path.common-dir * path.hooks * path.objects * path.toplevel Note to reviewers: I'd like to hear your thoughts on whether these paths should default to relative or absolute. My initial thought is relative by default with an `--absolute` flag, as that seems to match user expectations for CLI tools like `git rev-parse`. C. Enhancing git repo structure I want to add metrics inspired by `github/git-sizer` to help users assess repository health: * Maximum tree depth. * Identification of exceptionally large blobs (with a configurable byte threshold). I plan to implement this using the new path-walk API for fast, efficient traversal instead of slower rev-list approaches. ---------------------------------------------------------------------- 5. Timeline * Community Bonding (May 1 - May 26) Discuss the path schema (e.g., paths.* vs layout.paths.*) and relative/absolute defaults on the list. Finalize the exact git-sizer metrics we want to port over. * Phase 1: Libification & Metadata (May 27 - July 11) Weeks 1-2: Remove the_repository from builtin/repo.c. Standardize the use of the `repo` argument. Weeks 3-4: Implement category-based key filtering. Weeks 5-7: Implement path-related keys (git-dir, common-dir, toplevel, hooks, objects) and write tests in t/. * Phase 2: Advanced Structure Analysis (July 12 - Aug 18) Weeks 8-9: Integrate the path-walk API into cmd_repo_structure. Weeks 10-11: Implement tree depth counters and large object detection. Week 12: Buffer for fixing OS-specific path normalization issues and fine-tuning performance. * Wrap up (Aug 19 - Aug 26) Final documentation cleanup, polishing, and submitting the final report. ---------------------------------------------------------------------- 6. Risks & Mitigations * Path Normalization: Reporting paths correctly across Windows and Linux can be tricky. I will rely on normalize_path_copy() and ensure the test suite adequately covers edge cases on Windows environments. * Performance: Adding heavy checks to `structure` could slow it down. Utilizing path-walk mitigates this greatly, but I will also ensure these checks are fast enough on large repos (like linux.git) or place the deepest analytics behind an `--expensive` flag if necessary. ---------------------------------------------------------------------- 7. Availability I can commit 35-40 hours a week to this project over the summer. I plan to be highly active on the mailing list and IRC for reviews and discussions. ---------------------------------------------------------------------- 8. Resources & References To ensure my proposal aligns with the community's vision, I have been studying the following resources: * Original discussion on `git repo info`: https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u * Lucas Oshiro's exploratory branch for path metadata: https://github.com/lucasoshiro/git/compare/master...repo-info-path/ * The `github/git-sizer` repository for identifying ideal health metrics. * Official documentation for `git-repo(1)` and `git-rev-parse(1)`. ``` ## Lucas Seiki Oshiro, 2026-02-28 22:58 Subject: Re: [GSoC][PROPOSAL] Improving and Extending the git repo command Message-ID: URL: https://gitlist.dev/e/B8697AB9-9C9B-41C9-A2D8-1848CD966137%40gmail.com In-Reply-To: ``` > Hi everyone, Hi, Ayush! > Note to reviewers: I'd like to hear your thoughts on whether these > paths should default to relative or absolute. My initial thought is > relative by default with an `--absolute` flag, as that seems to match > user expectations for CLI tools like `git rev-parse`. I've just sent the path (trying to) add support for paths (the one you mentioned). I don't know if it's the best approach. I CC'ed you and the other GSoC applicants that are interested in git-repo-info. I wouldn't say that the user's expectations is to retrieve absolute paths by default, we need to check each one of the "options for files" modified by --path-format and see what makes more sense. See [1]. [1] fac60b8925 (rev-parse: add option for absolute or relative path formatting, 2020-12-13) ``` ## Ayush Jha, 2026-03-01 06:13 Subject: Re: [GSoC][PROPOSAL] Improving and Extending the git repo command Message-ID: URL: https://gitlist.dev/e/CAFNBzOe8_GbXFTmL5UuLWa%2B5xa%3DD04jJkmqMumerajeYGkVwaA%40mail.gmail.com In-Reply-To: ``` Hi Lucas, Thank you for this feedback and for pointing out commit fac60b8925! You are completely right—assuming a blanket "relative by default" expectation ignores the historical nuance of how git rev-parse handles different path options. I have updated my proposal draft to remove that assumption and properly acknowledge the complexity of path formatting for repo-info. I also just left my thoughts on your new repo-info --path-format patch series addressing this exact issue over on that thread! Let me know if that direction seems correct. (Also, apologies if my reply to that patch series looks a bit strange in your inbox—I accidentally put Jayatheerth in the 'To' field and you in 'CC' when replying!) Thanks again for the guidance, Ayush On Sun, Mar 1, 2026 at 4:28 AM Lucas Seiki Oshiro wrote: > > > > Hi everyone, > > Hi, Ayush! > > > Note to reviewers: I'd like to hear your thoughts on whether these > > paths should default to relative or absolute. My initial thought is > > relative by default with an `--absolute` flag, as that seems to match > > user expectations for CLI tools like `git rev-parse`. > > I've just sent the path (trying to) add support for paths (the one > you mentioned). I don't know if it's the best approach. I CC'ed you > and the other GSoC applicants that are interested in git-repo-info. > > I wouldn't say that the user's expectations is to retrieve absolute > paths by default, we need to check each one of the "options for > files" modified by --path-format and see what makes more sense. > See [1]. > > [1] fac60b8925 (rev-parse: add option for absolute or relative path formatting, 2020-12-13) ```