{"thread":{"id":"65266","subject":"[GSoC] Proposal draft: Improve the new git repo command","startedAt":"2026-03-16T13:08:14Z","lastAt":"2026-03-18T20:08:25Z","messageCount":5,"participants":["Jialong Wang","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"539106","messageId":"9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183@yahoo.com","threadId":"65266","inReplyTo":"9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183.ref@yahoo.com","subject":"[GSoC] Proposal draft: Improve the new git repo command","fromName":"Jialong Wang","fromEmail":"jerrywang183@yahoo.com","sentAt":"2026-03-16T11:47:13Z","receivedAt":"2026-03-16T13:08:14Z","isPatch":false,"sender":{"key":"jerrywang183@yahoo.com","avatar":null},"body":"Hi,\n\nI plan to apply to Git for GSoC 2026, and I would like to share a draft\nproposal for feedback.\n\nThe project I am currently most interested in is improving the new\n`git repo` command, with a primary focus on extending `git repo info`\nwith path-related repository metadata.\n\nMy draft is below. I would appreciate feedback on whether this scope\nlooks reasonable, and which parts of the current `git repo` work would\nmake the best starting point.\n\nThanks,\nJialong\n\n---\n\n# Improve `git repo info` by adding repository path metadata\n\n## Name\n\nJialong Wang\n\n## Email\n\njerrywang183@yahoo.com\n\n## Preferred project size\n\n175 hours\n\n## About me\n\nMy name is Jialong Wang, and I plan to apply to Git for GSoC 2026.\n\nI have been getting familiar with Git’s development workflow by building\nGit from source, reading the contribution documents, and working on a\nmicroproject. As part of that process, I prepared and sent a patch to\nthe Git mailing list.\n\nI am interested in the new `git repo` command because it is user-facing,\nbut also closely tied to Git’s internal repository model. That makes it\na good fit for the kind of work I want to do: understanding existing\ncode, discussing design details on the mailing list, and implementing\nimprovements in small, reviewable patches.\n\nRelevant links:\n\n- Microproject discussion thread:\n  https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n- Microproject patch thread:\n  https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n- SoC 2026 idea page:\n  https://git.github.io/SoC-2026-Ideas/\n\n## Project summary\n\nI would like to work on improving the new `git repo` command, with a\nprimary focus on `git repo info`.\n\nThe `git repo` command was introduced to provide a cleaner interface for\nquerying repository metadata. However, several useful path-related\nvalues are still mainly accessed through `git rev-parse` and\n`git rev-parse --git-path`. My proposal is to extend `git repo info`\nso that it can expose a selected set of those values in a more\nstructured form.\n\nThe goal is not to replace `git rev-parse`, but to make `git repo info`\nmore useful as a structured interface for repository path metadata.\n\n## Motivation\n\nToday, scripts and tools still often rely on commands such as:\n\n    git rev-parse --git-dir\n    git rev-parse --show-toplevel\n    git rev-parse --git-path <path>\n\nThese commands are useful, but they were not primarily designed as a\nstructured repository metadata interface.\n\nSince `git repo info` already exists for this purpose, extending it with\npath-related values would make repository layout information easier to\nquery in a cleaner and more consistent way.\n\nI think this is a good GSoC project because it has clear user value, can\nbe implemented incrementally, and naturally fits Git’s patch-and-review\nworkflow.\n\n## Current context\n\nI am aware that work on path-related `git repo info` fields has already\nstarted. There have already been patch series for path keys, category\nrequests, and path formatting. Because of that, I do not want to assume\nthat the work described on the ideas page is still untouched.\n\nOne of my first goals during the bonding period would be to review the\ncurrent state of these discussions carefully, identify what remains\nopen, and refine the project scope based on maintainer feedback. I would\nrather build on the current direction than duplicate work that is\nalready in progress.\n\nI also think this project should be scoped carefully. The ideas page\nmentions improvements to both `git repo info` and `git repo structure`,\nbut for a GSoC project I believe it is more realistic to focus first on\n`git repo info` and only expand beyond that if the main work is in good\nshape.\n\n## Proposed work\n\nThe main objective of this project is to extend `git repo info` with\nselected repository path values that are currently obtained through\n`git rev-parse` and `git rev-parse --git-path`.\n\nThe work will involve:\n\n1. Studying the current implementation of `git repo info`.\n2. Comparing its current output with commonly used `git rev-parse`\n   path queries.\n3. Identifying a first small set of missing path-related values to add.\n4. Discussing output design on the mailing list, especially where there\n   are open questions about relative versus absolute paths.\n5. Implementing the agreed functionality through small patch series.\n6. Adding tests covering the new behavior.\n7. Updating documentation if needed.\n\n## Initial scope\n\nThe first stage of the project would focus on a small set of commonly\nused repository path values, for example:\n\n- `git-dir`\n- `common-dir`\n- `toplevel`\n- `superproject-working-tree`\n\nI think these are a good first target because they are already familiar\nto users through `git rev-parse`, and they provide immediate practical\nvalue without requiring a large interface expansion.\n\nDepending on project progress and mailing list feedback, I would then\nlike to extend support to selected values currently accessed through\n`git rev-parse --git-path`, such as:\n\n- index file\n- objects directory\n- hooks directory\n\nI do not want to promise every possible path-related key up front. I\nwould rather start with the most straightforward and useful values, get\nfeedback early, and continue from there.\n\n## My approach to scope and quality\n\nOne thing I would like to be careful about is not treating this project\nas a simple checklist of fields to add.\n\nI think the quality of the project will depend on three things:\n\n1. choosing a small set of fields that make sense together,\n2. agreeing on a consistent path representation,\n3. and making sure the result fits naturally into the existing `git repo`\n   design rather than becoming a thin wrapper over `git rev-parse`.\n\nBecause of that, I would prefer to make progress in a few coherent\nbatches instead of adding many unrelated keys at once.\n\nI also think it is important to keep room for scope reduction. If some\npart of the design turns out to be more controversial than expected,\nI would prefer to complete a smaller, cleaner set of path fields rather\nthan stretching the project too broadly.\n\n## Technical approach\n\nThe implementation of `git repo` is primarily in `builtin/repo.c`. The\nfirst step would be to understand how `git repo info` currently collects\nand prints repository metadata, and how that existing structure can be\nextended without making the interface inconsistent.\n\nMany relevant repository paths are already available internally through\nhelpers such as:\n\n- `repo_get_git_dir()`\n- `repo_get_common_dir()`\n- `repo_get_work_tree()`\n\nSimilarly, `git rev-parse --git-path` already relies on existing path\nresolution logic. So the work is not about inventing these values from\nscratch, but about exposing a selected subset of them through\n`git repo info` in a way that fits its current design.\n\nThe first implementation step would be to map existing helpers and path\nresolution logic to a small set of `repo info` fields. After that, I\nwould extend the output code in `builtin/repo.c` to report those fields\nin a consistent way.\n\nOne of the main design questions is path formatting. The ideas page\nexplicitly mentions the need to decide between relative and absolute\npaths. I do not want to assume the answer in advance. Instead, I would\nreview the current discussion, compare the behavior of existing\ncommands, and propose a small, consistent approach on the mailing list.\n\nI also expect that some preparatory cleanup or refactoring may be useful\nbefore adding new fields. If so, I would keep that work minimal and send\nit as small separate patches.\n\n## Patch strategy\n\nI expect the implementation to be divided into small patches so that\neach change can be reviewed independently.\n\nA likely patch strategy would be:\n\n1. small preparatory cleanup if needed\n2. add support for a first path-related key or a very small set of keys\n3. extend support with additional related keys\n4. add or refine tests for the new behavior\n5. update documentation if necessary\n\nIf existing in-progress series already cover some of these parts, I\nwould adjust the breakdown accordingly and focus on what remains useful\nand open.\n\n## Tests\n\nTests would be added to cover the new behavior in common repository\nsetups.\n\nDepending on the exact scope agreed on, test cases may include:\n\n- ordinary repositories\n- linked worktrees\n- superproject/submodule cases\n- cases where path values differ from simple defaults\n\nI would keep the tests focused on observable behavior instead of\noverfitting them to a particular implementation detail.\n\n## What I will not try to do\n\nTo keep the project realistic, I do not plan to:\n\n- redesign all of `git repo`\n- fully replace `git rev-parse`\n- implement every possible repository path query\n- work on both `git repo info` and `git repo structure` at full scope in\n  the same project\n\nThe project should stay focused on a well-defined subset of path-related\nmetadata for `git repo info`.\n\n## Expected deliverables\n\nBy the end of the project, I expect to deliver:\n\n- support for a useful set of path-related values in `git repo info`\n- tests covering the new functionality\n- documentation updates if needed\n- one or more patch series discussed and refined on the Git mailing list\n\n## Timeline\n\n### Community bonding period\n\n- Study `builtin/repo.c` and the current `git repo info` implementation\n- Review recent and ongoing mailing list discussions related to `git repo`\n- Compare current `git repo info` behavior with `git rev-parse`\n- Refine the exact scope with mentors and mailing list feedback\n\n### Phase 1\n\n- Implement a first small batch of path-related values\n- Send the first patch series\n- Address review comments\n- Add tests for the first batch\n\n### Phase 2\n\n- Implement additional agreed path values\n- Continue design discussion if needed\n- Refine implementation and tests based on review feedback\n\n### Phase 3\n\n- Complete remaining agreed work\n- Update documentation if necessary\n- Rework earlier patches if needed for consistency\n- Prepare a final summary of the work\n\n### Buffer time\n\n- Handle review delays\n- Fix regressions or edge cases\n- Narrow scope if some planned work turns out to be too large\n\n## Risks and mitigation\n\nOne risk is that design discussion may take longer than expected,\nespecially around path representation and output structure.\n\nTo reduce that risk, I would keep the patch series small and prioritize\nthe least controversial values first.\n\nAnother risk is overlap with work already in progress. If that happens,\nI would adjust the project scope to avoid duplication and focus on what\nis still useful and open.\n\n## Why I think I am a good fit\n\nI have already started learning Git’s normal contribution workflow\nthrough a microproject, including building Git from source, running\ntests, preparing a patch, and sending it to the mailing list.\n\nThis project fits the kind of work I want to do in Git: understanding\nexisting code, discussing interface details on the mailing list, and\nimplementing improvements incrementally in small patches.\n\n## References\n\n- SoC 2026 idea page:\n  https://git.github.io/SoC-2026-Ideas/\n\n- General application information:\n  https://git.github.io/General-Application-Information/\n\n- `git repo` documentation:\n  https://git-scm.com/docs/git-repo\n\n- `git rev-parse` documentation:\n  https://git-scm.com/docs/git-rev-parse\n\n- `git-sizer` project:\n  https://github.com/github/git-sizer\n\n- Recent patch series adding path-related support to `git repo`:\n  https://public-inbox.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/\n\n- More recent work-in-progress series for category/path keys and\n  `--path-format`:\n  https://public-inbox.org/git/pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com/\n\n- Recent GSoC proposal thread on improving the new `git repo` command:\n  https://public-inbox.org/git/20260303140732.16886-1-pushkarkumarsingh1970@gmail.com/\n\n- Another recent GSoC proposal thread on improving/extending `git repo`:\n  https://public-inbox.org/git/CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com/\n\n- Recent proposal thread focused on the same SoC idea:\n  https://public-inbox.org/git/CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com/\n\n- Recent discussion around `git repo structure` enhancements:\n  https://public-inbox.org/git/CAO_P5U2f4MD-URre+4ocC=YQ570hr03pZHDk1jvuSOKx4aLOCA@mail.gmail.com/\n\n- Microproject discussion thread:\n  https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n\n- Microproject patch thread:\n  https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n\n- Review on the microproject patch thread:\n  https://public-inbox.org/git/CAOLa=ZTpfHUySnMgCFMnvo2JcRSv8zqFP-cLFSs+Ab5Cy2zsvg@mail.gmail.com/\n\n"},{"id":"539160","messageId":"CAOLa=ZQ7AMUb72N-0Z-h09KneE+ASuXt=BUOmO9Bzp4y6w6XyQ@mail.gmail.com","threadId":"65266","inReplyTo":"9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183@yahoo.com","subject":"Re: [GSoC] Proposal draft: Improve the new git repo command","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-03-16T20:59:44Z","receivedAt":"2026-03-16T20:59:45Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Jialong Wang <jerrywang183@yahoo.com> writes:\n\n> Hi,\n>\n> I plan to apply to Git for GSoC 2026, and I would like to share a draft\n> proposal for feedback.\n>\n> The project I am currently most interested in is improving the new\n> `git repo` command, with a primary focus on extending `git repo info`\n> with path-related repository metadata.\n>\n> My draft is below. I would appreciate feedback on whether this scope\n> looks reasonable, and which parts of the current `git repo` work would\n> make the best starting point.\n>\n> Thanks,\n> Jialong\n>\n> ---\n>\n> # Improve `git repo info` by adding repository path metadata\n>\n> ## Name\n>\n> Jialong Wang\n>\n> ## Email\n>\n> jerrywang183@yahoo.com\n>\n> ## Preferred project size\n>\n> 175 hours\n>\n> ## About me\n>\n> My name is Jialong Wang, and I plan to apply to Git for GSoC 2026.\n>\n> I have been getting familiar with Git’s development workflow by building\n> Git from source, reading the contribution documents, and working on a\n> microproject. As part of that process, I prepared and sent a patch to\n> the Git mailing list.\n>\n> I am interested in the new `git repo` command because it is user-facing,\n> but also closely tied to Git’s internal repository model. That makes it\n> a good fit for the kind of work I want to do: understanding existing\n> code, discussing design details on the mailing list, and implementing\n> improvements in small, reviewable patches.\n>\n> Relevant links:\n>\n> - Microproject discussion thread:\n>   https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n> - Microproject patch thread:\n>   https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n> - SoC 2026 idea page:\n>   https://git.github.io/SoC-2026-Ideas/\n>\n\nPerhaps it would be nice to give a few lines about what the microproject\ndiscussion thread and patch thread are about.\n\nIt also helps if you can state the current status, maybe look at other\nproposals for examples around this.\n\n> ## Project summary\n>\n> I would like to work on improving the new `git repo` command, with a\n> primary focus on `git repo info`.\n>\n> The `git repo` command was introduced to provide a cleaner interface for\n> querying repository metadata. However, several useful path-related\n> values are still mainly accessed through `git rev-parse` and\n> `git rev-parse --git-path`. My proposal is to extend `git repo info`\n> so that it can expose a selected set of those values in a more\n> structured form.\n>\n> The goal is not to replace `git rev-parse`, but to make `git repo info`\n> more useful as a structured interface for repository path metadata.\n>\n> ## Motivation\n>\n> Today, scripts and tools still often rely on commands such as:\n>\n>     git rev-parse --git-dir\n>     git rev-parse --show-toplevel\n>     git rev-parse --git-path <path>\n>\n> These commands are useful, but they were not primarily designed as a\n> structured repository metadata interface.\n>\n> Since `git repo info` already exists for this purpose, extending it with\n> path-related values would make repository layout information easier to\n> query in a cleaner and more consistent way.\n>\n> I think this is a good GSoC project because it has clear user value, can\n> be implemented incrementally, and naturally fits Git’s patch-and-review\n> workflow.\n>\n> ## Current context\n>\n> I am aware that work on path-related `git repo info` fields has already\n> started. There have already been patch series for path keys, category\n> requests, and path formatting. Because of that, I do not want to assume\n> that the work described on the ideas page is still untouched.\n>\n> One of my first goals during the bonding period would be to review the\n> current state of these discussions carefully, identify what remains\n> open, and refine the project scope based on maintainer feedback. I would\n> rather build on the current direction than duplicate work that is\n> already in progress.\n>\n\nIt would also make sense to have some sense of what that direction may\nlook like and add that to the proposal.\n\n> I also think this project should be scoped carefully. The ideas page\n> mentions improvements to both `git repo info` and `git repo structure`,\n> but for a GSoC project I believe it is more realistic to focus first on\n> `git repo info` and only expand beyond that if the main work is in good\n> shape.\n>\n\nThat's a fair assessment, what we do like to see is how you plan to\nstructure the goals and possibly future work into the timeline. Reading\non.\n\n> ## Proposed work\n>\n> The main objective of this project is to extend `git repo info` with\n> selected repository path values that are currently obtained through\n> `git rev-parse` and `git rev-parse --git-path`.\n>\n> The work will involve:\n>\n> 1. Studying the current implementation of `git repo info`.\n> 2. Comparing its current output with commonly used `git rev-parse`\n>    path queries.\n> 3. Identifying a first small set of missing path-related values to add.\n> 4. Discussing output design on the mailing list, especially where there\n>    are open questions about relative versus absolute paths.\n> 5. Implementing the agreed functionality through small patch series.\n> 6. Adding tests covering the new behavior.\n> 7. Updating documentation if needed.\n\nGenerally each commit should be self contained with tests and\ndocumentation, so perhaps 5, 6, 7 are a single point with subheadings?\n\n>\n> ## Initial scope\n>\n> The first stage of the project would focus on a small set of commonly\n> used repository path values, for example:\n>\n> - `git-dir`\n> - `common-dir`\n> - `toplevel`\n> - `superproject-working-tree`\n>\n> I think these are a good first target because they are already familiar\n> to users through `git rev-parse`, and they provide immediate practical\n> value without requiring a large interface expansion.\n>\n> Depending on project progress and mailing list feedback, I would then\n> like to extend support to selected values currently accessed through\n> `git rev-parse --git-path`, such as:\n>\n> - index file\n> - objects directory\n> - hooks directory\n>\n> I do not want to promise every possible path-related key up front. I\n> would rather start with the most straightforward and useful values, get\n> feedback early, and continue from there.\n>\n> ## My approach to scope and quality\n>\n> One thing I would like to be careful about is not treating this project\n> as a simple checklist of fields to add.\n>\n> I think the quality of the project will depend on three things:\n>\n> 1. choosing a small set of fields that make sense together,\n> 2. agreeing on a consistent path representation,\n> 3. and making sure the result fits naturally into the existing `git repo`\n>    design rather than becoming a thin wrapper over `git rev-parse`.\n>\n> Because of that, I would prefer to make progress in a few coherent\n> batches instead of adding many unrelated keys at once.\n>\n> I also think it is important to keep room for scope reduction. If some\n> part of the design turns out to be more controversial than expected,\n> I would prefer to complete a smaller, cleaner set of path fields rather\n> than stretching the project too broadly.\n>\n> ## Technical approach\n>\n> The implementation of `git repo` is primarily in `builtin/repo.c`. The\n> first step would be to understand how `git repo info` currently collects\n> and prints repository metadata, and how that existing structure can be\n> extended without making the interface inconsistent.\n>\n> Many relevant repository paths are already available internally through\n> helpers such as:\n>\n> - `repo_get_git_dir()`\n> - `repo_get_common_dir()`\n> - `repo_get_work_tree()`\n>\n> Similarly, `git rev-parse --git-path` already relies on existing path\n> resolution logic. So the work is not about inventing these values from\n> scratch, but about exposing a selected subset of them through\n> `git repo info` in a way that fits its current design.\n>\n> The first implementation step would be to map existing helpers and path\n> resolution logic to a small set of `repo info` fields. After that, I\n> would extend the output code in `builtin/repo.c` to report those fields\n> in a consistent way.\n>\n> One of the main design questions is path formatting. The ideas page\n> explicitly mentions the need to decide between relative and absolute\n> paths. I do not want to assume the answer in advance. Instead, I would\n> review the current discussion, compare the behavior of existing\n> commands, and propose a small, consistent approach on the mailing list.\n>\n> I also expect that some preparatory cleanup or refactoring may be useful\n> before adding new fields. If so, I would keep that work minimal and send\n> it as small separate patches.\n>\n\nSomething I would like to see is how we can leverage the existing tests\nfor `git-rev-parse(1)` and use them.\n\n> ## Patch strategy\n>\n> I expect the implementation to be divided into small patches so that\n> each change can be reviewed independently.\n>\n> A likely patch strategy would be:\n>\n> 1. small preparatory cleanup if needed\n> 2. add support for a first path-related key or a very small set of keys\n> 3. extend support with additional related keys\n> 4. add or refine tests for the new behavior\n> 5. update documentation if necessary\n>\n> If existing in-progress series already cover some of these parts, I\n> would adjust the breakdown accordingly and focus on what remains useful\n> and open.\n>\n> ## Tests\n>\n> Tests would be added to cover the new behavior in common repository\n> setups.\n>\n> Depending on the exact scope agreed on, test cases may include:\n>\n> - ordinary repositories\n> - linked worktrees\n> - superproject/submodule cases\n> - cases where path values differ from simple defaults\n>\n> I would keep the tests focused on observable behavior instead of\n> overfitting them to a particular implementation detail.\n>\n> ## What I will not try to do\n>\n> To keep the project realistic, I do not plan to:\n>\n> - redesign all of `git repo`\n> - fully replace `git rev-parse`\n> - implement every possible repository path query\n> - work on both `git repo info` and `git repo structure` at full scope in\n>   the same project\n>\n> The project should stay focused on a well-defined subset of path-related\n> metadata for `git repo info`.\n>\n> ## Expected deliverables\n>\n> By the end of the project, I expect to deliver:\n>\n> - support for a useful set of path-related values in `git repo info`\n> - tests covering the new functionality\n> - documentation updates if needed\n\nwouldn't documentation be definitely needed? ;)\n\n> - one or more patch series discussed and refined on the Git mailing list\n>\n> ## Timeline\n>\n> ### Community bonding period\n>\n> - Study `builtin/repo.c` and the current `git repo info` implementation\n> - Review recent and ongoing mailing list discussions related to `git repo`\n> - Compare current `git repo info` behavior with `git rev-parse`\n> - Refine the exact scope with mentors and mailing list feedback\n>\n> ### Phase 1\n>\n> - Implement a first small batch of path-related values\n> - Send the first patch series\n> - Address review comments\n> - Add tests for the first batch\n>\n> ### Phase 2\n>\n> - Implement additional agreed path values\n> - Continue design discussion if needed\n> - Refine implementation and tests based on review feedback\n>\n> ### Phase 3\n>\n> - Complete remaining agreed work\n> - Update documentation if necessary\n> - Rework earlier patches if needed for consistency\n> - Prepare a final summary of the work\n>\n> ### Buffer time\n>\n> - Handle review delays\n> - Fix regressions or edge cases\n> - Narrow scope if some planned work turns out to be too large\n>\n\nWe generally do timelines in terms of weeks of GSoC. So it would be nice\nto see that mapping over the phases mentioned here.\n\n> ## Risks and mitigation\n>\n> One risk is that design discussion may take longer than expected,\n> especially around path representation and output structure.\n>\n> To reduce that risk, I would keep the patch series small and prioritize\n> the least controversial values first.\n>\n> Another risk is overlap with work already in progress. If that happens,\n> I would adjust the project scope to avoid duplication and focus on what\n> is still useful and open.\n>\n> ## Why I think I am a good fit\n>\n> I have already started learning Git’s normal contribution workflow\n> through a microproject, including building Git from source, running\n> tests, preparing a patch, and sending it to the mailing list.\n>\n> This project fits the kind of work I want to do in Git: understanding\n> existing code, discussing interface details on the mailing list, and\n> implementing improvements incrementally in small patches.\n>\n> ## References\n>\n> - SoC 2026 idea page:\n>   https://git.github.io/SoC-2026-Ideas/\n>\n> - General application information:\n>   https://git.github.io/General-Application-Information/\n>\n> - `git repo` documentation:\n>   https://git-scm.com/docs/git-repo\n>\n> - `git rev-parse` documentation:\n>   https://git-scm.com/docs/git-rev-parse\n>\n> - `git-sizer` project:\n>   https://github.com/github/git-sizer\n>\n> - Recent patch series adding path-related support to `git repo`:\n>   https://public-inbox.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/\n>\n> - More recent work-in-progress series for category/path keys and\n>   `--path-format`:\n>   https://public-inbox.org/git/pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com/\n>\n> - Recent GSoC proposal thread on improving the new `git repo` command:\n>   https://public-inbox.org/git/20260303140732.16886-1-pushkarkumarsingh1970@gmail.com/\n>\n> - Another recent GSoC proposal thread on improving/extending `git repo`:\n>   https://public-inbox.org/git/CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com/\n>\n> - Recent proposal thread focused on the same SoC idea:\n>   https://public-inbox.org/git/CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com/\n>\n> - Recent discussion around `git repo structure` enhancements:\n>   https://public-inbox.org/git/CAO_P5U2f4MD-URre+4ocC=YQ570hr03pZHDk1jvuSOKx4aLOCA@mail.gmail.com/\n>\n> - Microproject discussion thread:\n>   https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n>\n> - Microproject patch thread:\n>   https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n>\n> - Review on the microproject patch thread:\n>   https://public-inbox.org/git/CAOLa=ZTpfHUySnMgCFMnvo2JcRSv8zqFP-cLFSs+Ab5Cy2zsvg@mail.gmail.com/\n\nRegards,\nKarthik\n"},{"id":"539163","messageId":"177369515432.95597.4924615522630208830.git-proposal-thanks@yahoo.com","threadId":"65266","inReplyTo":"9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183@yahoo.com","subject":"Re: [GSoC] Proposal draft: Improve the new git repo command","fromName":"Jialong Wang","fromEmail":"jerrywang183@yahoo.com","sentAt":"2026-03-16T21:05:54Z","receivedAt":"2026-03-16T21:26:13Z","isPatch":false,"sender":{"key":"jerrywang183@yahoo.com","avatar":null},"body":"Thanks for the feedback.\n\nThis is very helpful. I will revise the proposal to make the current\ndirection, the relationship to my microproject work, and the timeline\nmore concrete.\n\nThanks,\nJialong\n"},{"id":"539189","messageId":"20260317002848.6263-1-jerrywang183@yahoo.com","threadId":"65266","inReplyTo":"CAOLa=ZQ7AMUb72N-0Z-h09KneE+ASuXt=BUOmO9Bzp4y6w6XyQ@mail.gmail.com","subject":"Re: [GSoC] Proposal draft: Improve the new git repo command","fromName":"Jialong Wang","fromEmail":"jerrywang183@yahoo.com","sentAt":"2026-03-17T00:28:48Z","receivedAt":"2026-03-17T00:40:58Z","isPatch":false,"sender":{"key":"jerrywang183@yahoo.com","avatar":null},"body":"Hi Karthik,\n\nThanks for the detailed feedback. I revised the proposal draft to make the current status, intended scope, patch breakdown, and use of existing tests clearer. The updated draft is below.\n\nImprove Git Repo Info By Adding Repository Path Metadata\n\nName\nJialong Wang\n\nEmail\njerrywang183@yahoo.com\n\nPreferred project size\n175 hours\n\nAbout me\n\nMy name is Jialong Wang, and I plan to apply to Git for GSoC 2026.\n\nI have been getting familiar with Git's development workflow by building\nGit from source, reading the contribution documents, and working on a\nmicroproject. My microproject focused on improving corrupt patch\nlocation reporting in git apply and git am. That work has already gone\nthrough mailing list review, including comments from Karthik Nayak and\nJunio C Hamano, and it gave me direct experience with rerolling\npatches, updating tests, and using CI to catch gaps that I had missed\nlocally.\n\nMy broader programming experience has mainly involved systems-oriented\nsoftware, where I have had to read existing code, trace behavior\nthrough unfamiliar paths, and make targeted changes without disrupting\nsurrounding logic.\n\nAt this point, my recent Git contributions around this microproject are:\n\n1. an initial microproject patch series to report the location of\n   corrupt patches more clearly\n2. a follow-up patch to report input locations in header parsing errors\n   in apply.c\n3. a follow-up patch to report input locations in binary and garbage\n   patch error paths in apply.c\n\nThis has also helped me get comfortable with the normal Git workflow of\nstarting with a small change, responding to review, and then continuing\nwith a logically related follow-up.\n\nI am interested in the new git repo command because it is user-facing,\nbut also closely tied to Git's internal repository model. That makes it\na good fit for the kind of work I want to do: understanding existing\ncode, discussing design details on the mailing list, and implementing\nimprovements in small, reviewable patches.\n\nRelevant links\n\nMicroproject discussion thread\nThis thread asked whether improving corrupt patch location reporting was\na suitable microproject and helped me choose the work.\nhttps://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n\nMicroproject patch thread\nThis thread contains the patch itself, review, and rerolls for the\ncorrupt patch location reporting work.\nhttps://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n\nFollow-up patch\nThis follow-up patch extends the same idea to header parsing errors in\napply.c.\nhttps://public-inbox.org/git/20260316195847.92386-1-jerrywang183@yahoo.com/\n\nSecond follow-up patch\nThis follow-up patch extends the same idea to binary and garbage patch\nerror paths in apply.c and has also been sent to the mailing list. I\nwill add the public archive link once it is indexed.\nSubject: [GSoC PATCH] apply: report input location in binary and garbage patch errors\n\nSoC 2026 idea page\nhttps://git.github.io/SoC-2026-Ideas/\n\nProject summary\n\nI would like to work on improving the new git repo command, with a\nprimary focus on git repo info.\n\nThe git repo command was introduced to provide a cleaner interface for\nquerying repository metadata. However, several useful path-related\nvalues are still mainly accessed through git rev-parse and\ngit rev-parse --git-path. My proposal is to extend git repo info so\nthat it can expose a selected set of those values in a more structured\nform.\n\nThe goal is not to replace git rev-parse, but to make git repo info\nmore useful as a structured interface for repository path metadata.\n\nMotivation\n\nToday, scripts and tools still often rely on commands such as:\n\ngit rev-parse --git-dir\ngit rev-parse --show-toplevel\ngit rev-parse --git-path <path>\n\nThese commands are useful, but they were not primarily designed as a\nstructured repository metadata interface.\n\nSince git repo info already exists for this purpose, extending it with\npath-related values would make repository layout information easier to\nquery in a cleaner and more consistent way.\n\nI think this is a good GSoC project because it has clear user value, can\nbe implemented incrementally, and naturally fits Git's patch-and-review\nworkflow.\n\nCurrent context\n\nI am aware that work on path-related git repo info fields has already\nstarted. There have already been patch series for path keys, category\nrequests, and path formatting. Because of that, I do not want to assume\nthat the work described on the ideas page is still untouched.\n\nOne of my first goals during the bonding period would be to review the\ncurrent state of these discussions carefully, identify what remains\nopen, and refine the project scope based on maintainer feedback. I would\nrather build on the current direction than duplicate work that is\nalready in progress.\n\nMy recent apply.c follow-up patches are separate from git repo itself,\nbut they have already helped me get comfortable with Git's mailing list\nprocess, with responding to maintainer comments, and with organizing\nsmall changes into follow-up patches instead of overloading a single\nseries. I expect to approach git repo work in the same way.\n\nAt the moment, the direction that seems most realistic to me is to\nstart with a small set of layout-related fields that already have clear\nequivalents in git rev-parse, such as git-dir, common-dir, toplevel,\nand superproject-working-tree. I would prefer to begin there before\ntaking on broader questions such as category-wide output or possible\ngit repo structure extensions.\n\nMore concretely, if the current discussions do not point in a different\ndirection, I would expect my first implementation work to focus on a\nsmall initial series that adds one or a few of these layout-related\nfields to git repo info, together with tests and documentation for the\nsame behavior. I would treat that first series as the point where the\ncommunity can judge whether the field naming, path representation, and\noverall shape of the interface look right before I continue to a second\nbatch.\n\nIn other words, my current preference is:\n\n1. first settle a small batch of repo info path fields with clear\n   rev-parse equivalents\n2. then extend to a second batch of agreed path-related values from\n   rev-parse --git-path\n3. only after that consider whether category keys or other nearby repo\n   info improvements are worth taking on as stretch work\n\nI also think this project should be scoped carefully. The ideas page\nmentions improvements to both git repo info and git repo structure, but\nfor a GSoC project I believe it is more realistic to focus first on\ngit repo info and only expand beyond that if the main work is in good\nshape.\n\nProposed work\n\nThe main objective of this project is to extend git repo info with\nselected repository path values that are currently obtained through\ngit rev-parse and git rev-parse --git-path.\n\nI expect the work to proceed in four connected parts:\n\n1. Review the current implementation and ongoing mailing list\n   discussions, then narrow the initial scope to a first small batch of\n   path-related fields.\n2. Discuss output design on the mailing list, especially where there are\n   open questions about relative versus absolute paths and how the new\n   fields should fit the existing interface.\n3. Implement the agreed functionality through small patch series, with\n   each patch or small patch group carrying its own tests and any\n   documentation updates for the user-visible behavior.\n4. If the first batch is in good shape, extend support to a second\n   agreed batch of path-related fields.\n\nInitial scope\n\nThe first stage of the project would focus on a small set of commonly\nused repository path values, for example:\n\ngit-dir\ncommon-dir\ntoplevel\nsuperproject-working-tree\n\nI think these are a good first target because they are already familiar\nto users through git rev-parse, and they provide immediate practical\nvalue without requiring a large interface expansion.\n\nIf I had to choose an initial implementation order today, I would most\nlikely start with git-dir, common-dir, and toplevel first, because they\nseem like the most direct and broadly useful candidates. I would then\nlook at superproject-working-tree and selected git-path style values\nafter the first review round, rather than trying to push all of them in\nthe same initial series.\n\nDepending on project progress and mailing list feedback, I would then\nlike to extend support to selected values currently accessed through\ngit rev-parse --git-path, such as:\n\nindex file\nobjects directory\nhooks directory\n\nI do not want to promise every possible path-related key up front. I\nwould rather start with the most straightforward and useful values, get\nfeedback early, and continue from there.\n\nIf the core path-related work is in good shape, possible later work\ncould include small extensions around category keys or closely related\nrepo info behavior. I do not want to commit to that up front, but I do\nwant the timeline to make room for it as stretch work rather than as a\ncore deliverable.\n\nMy approach to scope and quality\n\nOne thing I would like to be careful about is not treating this project\nas a simple checklist of fields to add.\n\nI think the quality of the project will depend on three things:\n\n1. choosing a small set of fields that make sense together\n2. agreeing on a consistent path representation\n3. making sure the result fits naturally into the existing git repo\n   design rather than becoming a thin wrapper over git rev-parse\n\nBecause of that, I would prefer to make progress in a few coherent\nbatches instead of adding many unrelated keys at once.\n\nI also think it is important to keep room for scope reduction. If some\npart of the design turns out to be more controversial than expected,\nI would prefer to complete a smaller, cleaner set of path fields rather\nthan stretching the project too broadly.\n\nTechnical approach\n\nThe implementation of git repo is primarily in builtin/repo.c. The\nfirst step would be to understand how git repo info currently collects\nand prints repository metadata, and how that existing structure can be\nextended without making the interface inconsistent.\n\nMany relevant repository paths are already available internally through\nhelpers such as:\n\nrepo_get_git_dir()\nrepo_get_common_dir()\nrepo_get_work_tree()\n\nSimilarly, git rev-parse --git-path already relies on existing path\nresolution logic. So the work is not about inventing these values from\nscratch, but about exposing a selected subset of them through\ngit repo info in a way that fits its current design.\n\nThe first implementation step would be to map existing helpers and path\nresolution logic to a small set of repo info fields. After that, I\nwould extend the output code in builtin/repo.c to report those fields\nin a consistent way.\n\nIn the current implementation, git repo info is handled by\ncmd_repo_info() in builtin/repo.c. The currently supported keys are\ndefined in repo_info_field[], and the command prints values through\nprint_fields() and print_all_fields().\n\nA likely first implementation step would be to add new entries to\nrepo_info_field[] for the first batch of path-related keys, backed by\nnew getter functions that fit alongside existing ones such as\nget_layout_bare(), get_layout_shallow(), get_object_format(), and\nget_references_format(). The main user-facing path through the command\nwould still remain cmd_repo_info() together with the existing\nprint_fields() and print_all_fields() flow, so my goal would be to\nextend that structure rather than introduce a separate special case for\npath values.\n\nFor the initial batch, my expectation is that the implementation will\nmostly look like:\n\n1. identify which existing repository or path helper corresponds to the\n   field to be exposed\n2. add a getter that matches the shape expected by repo_info_field[]\n3. register the new field in repo_info_field[]\n4. update the output and tests to cover the new field\n5. update the documentation for the new field and its path format\n\nIn practical terms, I expect the first series to stay close to the\nexisting structure in builtin/repo.c rather than try to redesign it. If\nthe early fields are backed cleanly by helpers such as\nrepo_get_git_dir(), repo_get_common_dir(), or repo_get_work_tree(), I\nwould prefer to start there and let review on those patches shape the\napproach for later fields.\n\nFor path-related values, the main work would not be inventing new data,\nbut deciding which existing repository and path helpers should back\neach key and how those paths should be formatted consistently in\ngit repo info.\n\nOne of the main design questions is path formatting. The ideas page\nexplicitly mentions the need to decide between relative and absolute\npaths. I do not want to assume the answer in advance. Instead, I would\nreview the current discussion, compare the behavior of existing\ncommands, and propose a small, consistent approach on the mailing list.\n\nI also expect that some preparatory cleanup or refactoring may be useful\nbefore adding new fields. If so, I would keep that work minimal and send\nit as small separate patches.\n\nPatch strategy\n\nI expect the implementation to be divided into small patches so that\neach change can be reviewed independently.\n\nA likely patch strategy would be:\n\n1. small preparatory cleanup if needed\n2. add a first small batch of layout-related fields, together with the\n   tests and documentation updates needed for those fields\n3. extend support with additional agreed path-related fields, again with\n   matching tests and documentation updates\n\nFor the first batch, I currently expect something on the order of 4 to\n6 patches, depending on how much preparatory cleanup is useful and on\nwhether tests and documentation read more clearly combined with the\nfield patches or as separate follow-up patches in the same series. I do\nnot want to promise an exact count in advance, but I do want the first\nseries to stay small enough that each patch still has a clear purpose.\n\nI do not want to treat tests and documentation as a final clean-up\nstage. Since these are user-visible additions to git repo info, I think\nthe tests and documentation should evolve with each field batch, so\nthat the mailing list can review the interface and its description at\nthe same time as the implementation.\n\nIf existing in-progress series already cover some of these parts, I\nwould adjust the breakdown accordingly and focus on what remains useful\nand open.\n\nTests\n\nTests would be added alongside the new behavior rather than at the very\nend.\n\nDepending on the exact scope agreed on, test cases may include:\n\nordinary repositories\nlinked worktrees\nsuperproject and submodule cases\ncases where path values differ from simple defaults\n\nWhere possible, I would compare the new git repo info output against\nexisting git rev-parse behavior, since many of the proposed fields are\nalready exposed there. I would also look for opportunities to reuse or\nmirror the same repository layouts and edge cases that are already\nimportant to rev-parse, instead of inventing unrelated test-only cases.\n\nFor fields whose behavior is intentionally meant to correspond closely to\ngit rev-parse, I would like the tests to make that relationship clear.\nFor example, if a new git repo info field is meant to expose the same\ninformation as a particular rev-parse query, I would try to test both in\nthe same repository setup so that any differences are explicit and\nintentional rather than accidental.\n\nI would keep the tests focused on observable behavior instead of\noverfitting them to a particular implementation detail.\n\nWhat I will not try to do\n\nTo keep the project realistic, I do not plan to:\n\nredesign all of git repo\nfully replace git rev-parse\nimplement every possible repository path query\nwork on both git repo info and git repo structure at full scope in the\nsame project\n\nThe project should stay focused on a well-defined subset of path-related\nmetadata for git repo info.\n\nExpected deliverables\n\nBy the end of the project, I expect to deliver:\n\nsupport for a useful set of path-related values in git repo info\ntests covering the new functionality for those fields\ndocumentation updates for the new fields and their behavior\none or more patch series discussed and refined on the Git mailing list\n\nSuccess criteria\n\nI would consider the project successful if, by the end of the GSoC\nperiod, the following are true:\n\n1. a first useful batch of path-related git repo info fields has been\n   implemented and is in good shape on the mailing list, ideally merged\n   or close to merge-ready\n2. the new fields are covered by tests that clearly exercise the agreed\n   repository layouts and path behavior\n3. the documentation for those fields has been updated together with the\n   implementation\n4. if review and scope permit, at least one further agreed batch of\n   fields has also been implemented or is well advanced\n\nTimeline\n\nCommunity bonding period\n\nStudy builtin/repo.c and the current git repo info implementation\nReview recent and ongoing mailing list discussions related to git repo\nCompare current git repo info behavior with git rev-parse\nRefine the exact scope with mentors and mailing list feedback\nIdentify the first small batch of fields that looks realistic for an\ninitial patch series\nReview whether any in-progress series already cover part of that first\nbatch, so that I can avoid duplicating ongoing work\n\nWeek 1\n\nConfirm the exact first batch of fields to target\nPrepare and send an initial patch series for that batch\nInclude tests and documentation updates in that first series instead of\nleaving them to the end\n\nWeek 2\n\nAddress review comments on the initial series\nRevise the first batch if there is feedback about key naming, output\nshape, or relative versus absolute paths\nDecide whether the current direction is stable enough to continue with a\nsecond batch or whether the first batch needs another reroll first\n\nWeeks 3 to 4\n\nAddress review comments on the initial series\nRefine the first batch if there is feedback about field naming or path\nformatting\nSettle the first round of tests and documentation\nIf the first batch is accepted or close to settled, identify the exact\nsecond batch to work on next\n\nWeeks 5 to 6\n\nImplement a second agreed batch of path-related fields, likely selected\ngit rev-parse --git-path equivalents\nSend the next patch series with tests and documentation updates for\nthat batch\nKeep the second batch narrower than the first draft of the overall idea\nif review shows that path formatting or naming still needs discussion\n\nWeeks 7 to 8\n\nAddress review comments on the second batch\nRefine edge cases involving worktrees, submodules, or path formatting\nMake sure the user-visible behavior is documented clearly for whatever\nsubset of fields is actually agreed on\n\nWeeks 9 to 10\n\nFinish remaining agreed work\nUse the remaining time as buffer for rerolls, regressions, or scope\nreduction if needed\nIf the core path-related work is in good shape, investigate a small\nstretch item closely related to git repo info rather than branching out\ninto a separate large feature\n\nWeeks 11 to 12\n\nHandle any remaining review rounds on the core patch series\nPolish tests and documentation for the agreed set of fields\nUse the remaining time for final cleanup, rerolls, and project summary\nrather than for opening a new large piece of work\n\nCore goals for the project\n\n1. land or get close to landing a first useful batch of path-related\n   git repo info fields\n2. implement at least one further agreed batch if the first one is in\n   good shape\n3. keep tests and documentation updated as part of the patch series\n\nStretch work\n\n1. add a small extra batch beyond the core set if review cycles go well\n2. investigate a nearby repo info improvement such as a small category\n   or interface refinement, but only if the main path-related work is\n   already in good shape\n\nRisks and mitigation\n\nOne risk is that design discussion may take longer than expected,\nespecially around path representation and output structure.\n\nTo reduce that risk, I would keep the patch series small and prioritize\nthe least controversial values first.\n\nAnother risk is overlap with work already in progress. If that happens,\nI would adjust the project scope to avoid duplication and focus on what\nis still useful and open.\n\nWhy I think I am a good fit\n\nI have already started learning Git's normal contribution workflow\nthrough a microproject, including building Git from source, running\ntests, preparing patches, responding to review, and rerolling them on\nthe mailing list.\n\nThis project is a good fit for me because it requires exactly the kind\nof work I have already started doing in Git: reading existing code\npaths carefully, making small user-visible improvements, and refining\nthe result through review rather than trying to force a large one-shot\ndesign.\n\nReferences\n\nOfficial and technical references\n\nSoC 2026 idea page\nhttps://git.github.io/SoC-2026-Ideas/\n\nGeneral application information\nhttps://git.github.io/General-Application-Information/\n\ngit repo documentation\nhttps://git-scm.com/docs/git-repo\n\ngit rev-parse documentation\nhttps://git-scm.com/docs/git-rev-parse\n\ngit-sizer project\nhttps://github.com/github/git-sizer\n\nRelevant mailing list threads\n\nRecent patch series adding path-related support to git repo\nhttps://public-inbox.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/\n\nMore recent work-in-progress series for category and path keys and\npath-format\nhttps://public-inbox.org/git/pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com/\n\nRecent GSoC proposal thread on improving the new git repo command\nhttps://public-inbox.org/git/20260303140732.16886-1-pushkarkumarsingh1970@gmail.com/\n\nAnother recent GSoC proposal thread on improving and extending git repo\nhttps://public-inbox.org/git/CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com/\n\nRecent proposal thread focused on the same SoC idea\nhttps://public-inbox.org/git/CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com/\n\nRecent discussion around git repo structure enhancements\nhttps://public-inbox.org/git/CAO_P5U2f4MD-URre+4ocC=YQ570hr03pZHDk1jvuSOKx4aLOCA@mail.gmail.com/\n\nMicroproject discussion thread\nhttps://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n\nMicroproject patch thread\nhttps://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n\nReview on the microproject patch thread\nhttps://public-inbox.org/git/CAOLa=ZTpfHUySnMgCFMnvo2JcRSv8zqFP-cLFSs+Ab5Cy2zsvg@mail.gmail.com/\n\nFollow-up patch for header parsing errors\nhttps://public-inbox.org/git/20260316195847.92386-1-jerrywang183@yahoo.com/\n\nFollow-up patch for binary and garbage patch errors\nSent to the mailing list; public archive link to be added once indexed.\nSubject: [GSoC PATCH] apply: report input location in binary and garbage patch errors\n\n\nThanks,\nJialong\n"},{"id":"539319","messageId":"20260318200816.31430-1-jerrywang183@yahoo.com","threadId":"65266","inReplyTo":"CAOLa=ZQ7AMUb72N-0Z-h09KneE+ASuXt=BUOmO9Bzp4y6w6XyQ@mail.gmail.com","subject":"[GSoC proposal v3][RFC] Improve the new git repo command","fromName":"Jialong Wang","fromEmail":"jerrywang183@yahoo.com","sentAt":"2026-03-18T20:08:16Z","receivedAt":"2026-03-18T20:08:25Z","isPatch":false,"sender":{"key":"jerrywang183@yahoo.com","avatar":null},"body":"Hi all,\n\nThis is v3 of my proposal draft for the \"Improve the new git repo\ncommand\" project. I am including the full draft inline below for\nconvenience.\n\nIn this revision, I tried to make the scope more realistic and better\naligned with the current public discussion around `git repo info`. In\nparticular, I:\n\n- revised the proposal so it does not assume that path-related `git repo\n  info` work is starting from scratch\n- reframed the project around integration, testing, repository-aware\n  cleanup, and any still-open metadata gaps\n- added my more recent Git contributions\n- added a short \"immediate next steps\" section describing the kind of\n  `git repo` patch I want to work on next before the coding period\n\nI would appreciate any feedback from mentors and reviewers on whether\nthis revised framing is closer to the right direction.\n\nThanks for any feedback,\nJialong\n\n\nImprove the git repo command\n\nName\nJialong Wang\n\nEmail\njerrywang183@yahoo.com\n\nPreferred project size\n175 hours\n\nAbout me\n\nMy name is Jialong Wang, and I plan to apply to Git for GSoC 2026.\n\nI have been getting familiar with Git's development workflow by building\nGit from source, reading the contribution documents, and working on\npatches through the mailing list. My initial microproject focused on\nimproving corrupt patch location reporting in `git apply` and `git am`.\nThat work went through mailing-list review, including comments from\nKarthik Nayak and Junio C Hamano, and gave me direct experience with\nrerolling patches, updating tests, and using CI to catch gaps I had\nmissed locally.\n\nSince then, I have continued contributing small Git patches and\nfollow-up work instead of stopping after the microproject. My recent\ncontributions include:\n\n1. an initial patch series to report the location of corrupt patches\n   more clearly\n2. a follow-up patch to report input locations in header parsing errors\n   in `apply.c`\n3. a follow-up patch to report input locations in binary and garbage\n   patch error paths in `apply.c`\n4. `t2203: avoid suppressing git status exit code`\n5. `object-name: turn INTERPRET_BRANCH_* constants into enum values`\n\nThis has helped me get comfortable with Git's normal workflow of\nstarting with a small change, responding to review, rerolling\nappropriately, and then continuing with logically related follow-up\nwork.\n\nProject summary\n\nI would like to work on improving the new `git repo` command, with a\nprimary focus on `git repo info`.\n\nThe `git repo` command was introduced to provide a cleaner interface for\nquerying repository metadata. Path-related values are a natural part of\nthat goal, but the public discussion this year has already shown that\nthis topic is not starting from zero: there is ongoing work around\npath-related fields, category-aware key naming, and path-format\nbehavior.\n\nBecause of that, I do not want to frame this proposal as \"I will newly\nadd repository path metadata\" in isolation. Instead, my proposal is to\nimprove `git repo info` by building on the direction already taking\nshape upstream, focusing on integration, testing, repository-aware\ncleanup, and any remaining path-related or adjacent metadata work that\nis still useful and unimplemented by the time GSoC begins.\n\nThe goal is not to replace `git rev-parse`, but to make `git repo info`\na more coherent and better-tested structured interface for repository\nmetadata.\n\nMotivation\n\nToday, scripts and tools still often rely on commands such as:\n\n- `git rev-parse --git-dir`\n- `git rev-parse --show-toplevel`\n- `git rev-parse --git-path <path>`\n\nThese commands are useful, but they were not primarily designed as a\nstructured repository metadata interface.\n\nSince `git repo info` already exists for this purpose, extending and\nrefining it would make repository layout information easier to query in\na cleaner and more consistent way. However, given the current public\nwork in progress, I think the most useful contribution is not to\nduplicate existing series, but to help move this area toward a better\nintegrated and upstream-ready state.\n\nCurrent context\n\nI am aware that work on path-related `git repo info` fields has already\nstarted. There have already been patch series and proposal discussions\nfor path keys, category requests, path formatting, and nearby\n`git repo structure` ideas.\n\nBecause of that, one of my first goals during the bonding period would\nbe to review the current state of those discussions carefully, identify\nwhat remains open, and refine the exact project scope based on mentor\nfeedback. I would rather build on the current direction than duplicate\nwork that is already in progress.\n\nAt this point, the direction that seems most realistic to me is:\n\n1. first align with the upstream direction that is already emerging for\n   `git repo info`\n2. improve the command's internal consistency and test coverage\n3. implement remaining path-related or adjacent metadata work only where\n   it is still clearly useful and not already being covered elsewhere\n\nImmediate next steps\n\nBefore the coding period, I want to keep contributing in this area\nthrough small reviewable patches instead of waiting until GSoC starts.\n\nMy immediate plan is:\n\n1. review the latest upstream state of the path-related and\n   category-related `git repo info` work\n2. identify one small `git repo` patch that does not duplicate an\n   in-flight series\n3. start either with a repository-aware cleanup in `builtin/repo.c` or\n   with stronger tests in `t/t1900-repo-info.sh`, depending on which\n   direction is still open and useful\n4. use that first patch series to validate the project direction with\n   the mailing list before committing to a larger implementation batch\n\nProposed work\n\nThe main objective of this project is to improve `git repo info` as a\nstructured repository metadata interface while avoiding duplication of\npublic in-flight work.\n\nI expect the work to proceed in four connected parts:\n\n1. review the current implementation and ongoing mailing-list\n   discussions, then narrow the initial scope to a first small batch of\n   cleanup, tests, or still-open metadata work\n2. discuss design details on the mailing list, especially where there\n   are open questions about path naming, path formatting, or the\n   relationship with existing `git rev-parse` behavior\n3. implement the agreed functionality through small patch series, with\n   each patch or small patch group carrying its own tests and\n   documentation updates for the user-visible behavior\n4. if the first batch is in good shape, extend support to a second\n   agreed batch of improvements, whether that means remaining\n   path-related fields, repository-aware cleanup, or nearby metadata\n   work that still appears useful\n\nInitial scope\n\nAt the beginning of the project, I would prefer to keep the first\npractical batch conservative.\n\nRather than assuming that the first implementation work should directly\nadd a large number of path keys, I would prefer to start from one of\nthese two realistic entry points, depending on the state of upstream\nwork:\n\n1. a small batch of still-unimplemented layout-related fields with clear\n   `rev-parse` equivalents, if those remain open\n2. repository-aware cleanups and stronger tests around `git repo info`,\n   if the path-field direction is already substantially covered by\n   existing series\n\nIf path-related values are still a good first target by the beginning of\nthe coding period, the most likely initial candidates would be a small\nset of high-value layout paths such as:\n\n- `git-dir`\n- `common-dir`\n- `toplevel`\n- `superproject-working-tree`\n\nIf those are already substantially addressed, I would instead prioritize\ncleanups and tests that help the command mature, for example:\n\n- reducing unnecessary reliance on global repository state inside\n  `builtin/repo.c`\n- strengthening coverage in `t/t1900-repo-info.sh`\n- covering edge cases such as linked worktrees and `--separate-git-dir`\n\nTechnical approach\n\nThe implementation of `git repo` is primarily in `builtin/repo.c`. The\nfirst step would be to understand how `git repo info` currently collects\nand prints repository metadata, and how that existing structure can be\nextended or cleaned up without making the interface inconsistent.\n\nMany relevant repository values are already available internally through\nhelpers such as:\n\n- `repo_get_git_dir()`\n- `repo_get_common_dir()`\n- `repo_get_work_tree()`\n\nSimilarly, `git rev-parse` and `git rev-parse --git-path` already rely\non existing path resolution logic. So the work is not about inventing\nthese values from scratch, but about exposing or integrating a selected\nsubset of them through `git repo info` in a way that fits its current\ndesign.\n\nPatch strategy\n\nI expect the implementation to be divided into small patches so that\neach change can be reviewed independently.\n\nA likely patch strategy would be:\n\n1. a small preparatory cleanup if needed\n2. a first small batch of `git repo` improvements, together with the\n   tests and documentation updates needed for those changes\n3. a second batch that extends the same direction once the first one is\n   reviewed\n\nI do not want to treat tests and documentation as a final cleanup\nstage. Since these are user-visible changes to `git repo info`, I think\nthey should evolve with each patch batch so that the mailing list can\nreview the interface and its description at the same time as the\nimplementation.\n\nTests\n\nTests would be added alongside the new behavior rather than at the very\nend.\n\nDepending on the exact scope agreed on, test cases may include:\n\n- ordinary repositories\n- linked worktrees\n- superproject and submodule cases\n- repositories created with `--separate-git-dir`\n- cases where path values differ from simple defaults\n\nWhere possible, I would compare new `git repo info` behavior against\nexisting `git rev-parse` behavior when the semantics are intentionally\nclose. I would also look for opportunities to reuse or mirror repository\nlayouts and edge cases that are already important elsewhere.\n\nWhat I will not try to do\n\nTo keep the project realistic, I do not plan to:\n\n- redesign all of `git repo`\n- fully replace `git rev-parse`\n- reimplement path-related work that is already being actively reviewed\n- work on both `git repo info` and `git repo structure` at full scope in\n  the same project\n\nExpected deliverables\n\nBy the end of the project, I expect to deliver:\n\n- support for a useful set of `git repo info` improvements that are\n  still clearly open and upstream-relevant\n- tests covering the new functionality and relevant repository layouts\n- documentation updates for the new fields or behavior\n- one or more patch series discussed and refined on the Git mailing list\n\nSuccess criteria\n\nI would consider the project successful if, by the end of the GSoC\nperiod, the following are true:\n\n1. a first useful batch of `git repo` improvements has been implemented\n   and is in good shape on the mailing list, ideally merged or close to\n   merge-ready\n2. the new or refined behavior is covered by tests that clearly\n   exercise the agreed repository layouts and semantics\n3. the documentation has been updated together with the implementation\n4. if review and scope permit, at least one further agreed batch of\n   improvements has also been implemented or is well advanced\n\nTimeline\n\nCommunity bonding period\n\n- study `builtin/repo.c` and the current `git repo info` implementation\n- review recent and ongoing mailing-list discussions related to\n  `git repo`\n- compare current `git repo info` behavior with related\n  `git rev-parse` behavior\n- refine the exact scope with mentors and mailing-list feedback\n- identify the first small batch of work that looks realistic for an\n  initial patch series\n\nWeeks 1-3\n\n- confirm the exact first batch of work to target\n- prepare and send an initial patch series for that batch\n- include tests and documentation updates in that first series\n- address review comments and reroll as needed\n\nWeeks 4-6\n\n- continue strengthening semantics and coverage\n- add tests for edge cases such as linked worktrees and\n  `--separate-git-dir`\n- resolve small interface inconsistencies discovered during the early\n  cleanup work\n\nWeeks 7-9\n\n- finish or polish any remaining path/category/path-format work that\n  still needs implementation or integration\n- coordinate patch scope with the latest upstream discussion\n- update documentation to match settled behavior\n\nWeeks 10-12\n\n- implement one or more remaining metadata or interface improvements\n  that are still clearly useful and unclaimed\n- focus on review-driven cleanup, additional tests, and documentation\n  polish\n- prepare final report and project summary\n\nRisks and mitigation\n\nThe main risk is overlap with parallel upstream work. I plan to mitigate\nthat by treating the project as integration-oriented from the beginning,\nkeeping patch series small, and adjusting scope based on the latest\npublic discussion and mentor guidance.\n\nA second risk is that some of the path-related work may be largely\nsettled before the coding period starts. If that happens, I would shift\neffort toward repository-aware cleanups, stronger test coverage,\ndocumentation alignment, and other still-open `git repo` improvements\nrather than forcing redundant feature work.\n\nWhy I think I am a good fit\n\nI have already invested time in learning Git's contribution process\nthrough actual submissions rather than only private experimentation.\nThat includes building the project, reading tests, sending patches,\nrerolling in response to feedback, and adjusting patch structure when\nmaintainers asked for it.\n\nI believe that experience is directly relevant here. The main challenge\nof this project is not only writing code, but also moving an evolving\ncommand forward in an upstream-friendly way without duplicating parallel\nwork. My recent contributions have helped me understand that process\nmuch better, and I believe they put me in a stronger position to carry\nthis project successfully.\n\nRelevant links\n\nSoC 2026 idea page\nhttps://git.github.io/SoC-2026-Ideas/\n\nGeneral application information\nhttps://git.github.io/General-Application-Information/\n\ngit repo documentation\nhttps://git-scm.com/docs/git-repo\n\ngit rev-parse documentation\nhttps://git-scm.com/docs/git-rev-parse\n\nRecent patch series adding path-related support to git repo\nhttps://public-inbox.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/\n\nRecent work-in-progress series for category and path keys and\n`--path-format`\nhttps://public-inbox.org/git/pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com/\n\nRecent GSoC proposal thread on improving the new git repo command\nhttps://public-inbox.org/git/20260303140732.16886-1-pushkarkumarsingh1970@gmail.com/\n\nAnother recent GSoC proposal thread on improving and extending git repo\nhttps://public-inbox.org/git/CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com/\n\nRecent proposal thread focused on the same SoC idea\nhttps://public-inbox.org/git/CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com/\n\nMicroproject discussion thread\nhttps://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/\n\nMicroproject patch thread\nhttps://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/\n\nFollow-up patch for header parsing errors\nhttps://public-inbox.org/git/20260316195847.92386-1-jerrywang183@yahoo.com/\n"}]}