{"thread":{"id":"65343","subject":"[GSoC][PROPOSAL] Improve the new git repo command","startedAt":"2026-03-24T05:00:12Z","lastAt":"2026-03-24T05:00:12Z","messageCount":1,"participants":["jayesh0104"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"539805","messageId":"20260324045904.44384-1-jayeshdaga99@gmail.com","threadId":"65343","inReplyTo":null,"subject":"[GSoC][PROPOSAL] Improve the new git repo command","fromName":"jayesh0104","fromEmail":"jayeshdaga99@gmail.com","sentAt":"2026-03-24T04:58:43Z","receivedAt":"2026-03-24T05:00:12Z","isPatch":false,"sender":{"key":"jayeshdaga99@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86013121?v=4"},"body":"Hi all,\n\nI am Jayesh Daga, a third-year Computer Science undergraduate at VIT Chennai.\nI would like to submit my proposal for the GSoC 2026 project: \"Improve the new git repo command\".\nI would greatly appreciate feedback from the community and mentors.\n\n---\n\n== 1. Personal Information\n\nName: Jayesh Daga\nEmail: jayeshdaga99@gmail.com\nGitHub: https://github.com/jayesh0104\nUniversity: Vellore Institute of Technology, India\nTimezone: IST (UTC+5:30)\nAvailability: 35–40 hours/week (May–August 2026)\n\n---\n\n== 2. About Me\n\nI am a systems-oriented developer with a strong interest in developer tools,\nversion control systems, and backend infrastructure.\n\nI have experience in C, C++, Python, and JavaScript, and have worked on:\n- real-time telemetry systems\n- CI/CD pipelines\n- backend services\n\nI enjoy working close to system internals, where small design decisions\ncan significantly impact usability and performance.\n\n---\n\n== 3. Contributions to Git\n\nI have actively contributed to the Git project, particularly in improving\ntest consistency and aligning with Git’s internal testing framework.\n\n- Replaced raw file checks with `test_path_is_missing` to align with\n  Git’s testing conventions\n- Fixed incorrect helper usage that could lead to test failures\n\nOne of my patches has been integrated into the `next` branch of Git,\nindicating that it has passed initial review and integration stages.\n\nI have participated in the full upstream contribution workflow:\n- Sending patches via git-send-email\n- Engaging in mailing list discussions\n- Responding to maintainer feedback\n- Submitting revised versions (v2, v3)\n\nFor example, after feedback from a Git contributor, I identified a mismatch\nbetween the commit message and the actual code change and submitted a\ncorrected v3 patch.\n\nThrough this process, I gained a strong understanding of:\n- Git’s test framework and helper utilities\n- The importance of precise commit messages\n- Incremental patch-based development and review cycles\n\n---\n\n== 4. Project Overview\n\nThe `git repo` command is a recent addition intended to provide a\nstructured interface for querying repository metadata and structure.\n\nHowever, it currently:\n- lacks coverage for many commonly used values\n- has limited structure in output\n- does not yet serve as a unified abstraction over existing commands\n\nThis project aims to evolve `git repo` into a complete, consistent,\nand script-friendly interface for repository introspection.\n\n---\n\n== 5. Problem Statement\n\nCurrently, repository metadata is fragmented across multiple commands:\n\n- `git rev-parse` → paths and repository state\n- `git config` → configuration\n- external tools like git-sizer → repository metrics\n\nThis results in:\n- fragmentation (multiple commands required)\n- inconsistent output formats\n- lack of a unified abstraction\n\nThe `git repo` command is intended to address this, but remains incomplete.\n\n---\n\n== 6. Technical Proposal\n\nThe implementation will primarily involve extending logic in\n`builtin/repo.c`, reusing existing helpers used by commands like\n`rev-parse`, and ensuring consistency with Git’s internal APIs.\n\n### 6.1 Path Metadata Expansion\n\nAdd support for:\n\nCore paths:\n- paths.git_dir\n- paths.common_dir\n- paths.toplevel\n- paths.superproject_working_tree\n\nGit-path equivalents:\n- paths.objects\n- paths.index\n- paths.hooks\n- paths.grafts\n- paths.prefix\n\nDesign:\n- Default to relative paths (portable)\n- Optional `--absolute` flag\n\nFinal decisions will be made through mailing list discussion.\n\n---\n\n### 6.2 Structured Output\n\nCurrent output is flat key-value.\n\nProposed:\n\n{\n  \"paths\": { ... },\n  \"layout\": { ... }\n}\n\nBenefits:\n- easier machine parsing\n- better extensibility\n- clearer organization\n\nBackward compatibility will be preserved.\n\n---\n\n### 6.3 Remove Global State\n\nReplace usage of global `the_repository` with explicit:\n\n    struct repository *repo\n\nBenefits:\n- improved modularity\n- better testability\n- future extensibility\n\n---\n\n### 6.4 Extend `git repo structure`\n\nAdd metrics inspired by git-sizer:\n- object counts\n- largest blobs\n- tree depth\n\nEnsure:\n- incremental additions\n- performance safety\n\n---\n\n### 6.5 Testing and Documentation\n\nTesting:\n- extend tests in `t/`\n- cover edge cases (bare repos, worktrees, submodules)\n\nDocumentation:\n- update `git-repo.txt`\n- include examples and usage patterns\n\n---\n\n== 7. Timeline\n\nCommunity Bonding:\n- study relevant code (`builtin/repo.c`, `repository.c`, `setup.c`)\n- initiate mailing list discussions (paths, structure)\n- submit small patch\n\nWeeks 1–2:\n- implement core path metadata\n- testing and review\n\nWeeks 3–4:\n- implement git-path equivalents\n- ensure parity with rev-parse\n\nWeeks 5–6:\n- refactor global state usage\n- submit incremental patches\n\nWeeks 7–8:\n- structured output implementation\n- RFC discussion and iteration\n\nWeeks 9–10:\n- extend repo structure metrics\n- validate performance\n\nWeeks 11–12:\n- polishing, documentation, final review\n\n---\n\n== 8. Risks and Mitigation\n\nDesign disagreements:\n- addressed via early RFC discussions\n\nPerformance concerns:\n- benchmark before merging\n- optional flags for expensive operations\n\nReview delays:\n- mitigated through small, incremental patches\n\n---\n\n== 9. Why Me\n\nI have already contributed to Git and worked through its mailing list\ndevelopment workflow.\n\nHaving a patch integrated into the `next` branch and iterating through\nv2 and v3 revisions has given me practical experience with Git’s\nexpectations around correctness, clarity, and incremental changes.\n\nMy background in systems programming allows me to reason about API design,\nperformance trade-offs, and maintainability—key aspects of this project.\n\n---\n\n== 10. Future Work\n\nI intend to continue contributing to Git beyond GSoC, particularly in:\n- stabilizing `git repo` as a porcelain command\n- improving developer-facing tooling\n\n---\n\nThank you for your time and consideration. I would greatly appreciate\nany feedback on this proposal.\n\nThanks,\nJayesh Daga\n"}]}