{"thread":{"id":"65265","subject":"[GSoC][RFC v2] Proposal: Improve the new git repo command","startedAt":"2026-03-16T13:04:39Z","lastAt":"2026-03-18T13:42:13Z","messageCount":4,"participants":["Pushkar Singh","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"539105","messageId":"20260316130431.1318-1-pushkarkumarsingh1970@gmail.com","threadId":"65265","inReplyTo":null,"subject":"[GSoC][RFC v2] Proposal: Improve the new git repo command","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-03-16T13:04:31Z","receivedAt":"2026-03-16T13:04:39Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Everyone,\nThis is the second version of my proposal for \"Improve the new git repo command\" in Google Summer of Code 2026. \n\nThe Doc version:\nhttps://docs.google.com/document/d/1HM1HNQqUrGdqFdUppc02BTmPuwXC2ozCw9mLrbaVUHc/edit?usp=sharing\n\nI'd appreciate any feedback on this.\n\nThanks,\nPushkar\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\n\nGSoC 2026 @ Git | Pushkar Singh\nImprove the new git repo command\n---------------------------------------------------\n\n\nPersonal Information:\n---------------------\nName: Pushkar Singh\nE-mail: pushkarkumarsingh1970@gmail.com\n\nEducation: XIM University, Bhubaneswar, Odisha, India\nYear: II/III\nDegree: Bachelors in Computer Science & Engineering\n\nTime-Zone: UTC + 5:30 (IST)\n\nPersonal page: https://pushkarscripts.com/\nBlog: https://medium.com/@pushkarscripts/\nGitHub: https://github.com/pushkarscripts/\n\n\nPre-GSOC:\n---------\n\nI began exploring Git’s codebase by studying its documentation, \nreviewing prior mailing list discussions, and building Git from \nsource. \nI focused on understanding the test framework, patch submission \nworkflow using git send-email, versioned patch iteration, and \nthe review culture on the mailing list.\n\nAfter becoming familiar with the contribution process, I started \nsubmitting patches.\n\n\nContributions to Git (Chronological Order):\n-------------------------------------------\n\n* [PATCH v4] t1300: use test helpers instead of test builtins\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260104194812.15134-1-pushkarkumarsingh1970@gmail.com/t/#u\nThis patch is my first contribution to fulfill microproject \ncriteria. It replaces legacy test -f and test -h checks with \ntest_path_is_file and test_path_is_symlink in the test suite.\n\n* [PATCH v2] t1410: use test helpers in reflog rewind test\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260111191525.17087-1-pushkarkumarsingh1970@gmail.com/t/#u\nReplaced raw file existence checks in the reflog rewind test \nwith test_path_is_file and test_path_is_missing. The subject \nand commit message were refined in v2 following review feedback.\n\n* [PATCH] Documentation/config: fix replacement for --get-urlmatch\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260115110832.15315-1-pushkarkumarsingh1970@gmail.com/T/#u\n    Related Bug Report: https://lore.kernel.org/git/CAGJzqs=0Zr2iqsTUZdjdwpbtaS7kuBOf=E_XT=vbdfyNTKkjNQ@mail.gmail.com/t/#u\nCorrected documentation that incorrectly suggested combining \n--url with --all for --get-urlmatch. Verified the behavior \nagainst the implementation and updated the documentation \naccordingly.\n\n* [PATCH v3] path: refactor normalize_path_copy_len for clarity\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260221110511.1592-2-pushkarkumarsingh1970@gmail.com/t/#u\nProposed a refactor of normalize_path_copy_len to improve \nclarity while preserving existing control flow. The discussion\nfocused on maintaining readability and minimizing structural \nchanges.\n\n* [PATCH v4] subtree: validate --prefix against commit in split\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260203164815.68258-2-pushkarkumarsingh1970@gmail.com/T/#u\n    Related Bug Report: https://lore.kernel.org/git/CAFePT4xDGegpEFuFemCXsH890E2WXnG3JzUZeiLi9KW8D8beOg@mail.gmail.com/T/#u\nUpdated git subtree split to validate --prefix against the \nspecified commit rather than the working tree. The change \naddresses a mailing list report where --prefix was incorrectly \nvalidated against the current working directory instead of the \ngiven revision. Added regression tests and revised the patch \nacross four versions following review and CI feedback before \nintegration into next.\n\n* [RFC] git repo info: expose repository paths\n    Status: WIP, Under discussion\n    Thread: https://lore.kernel.org/git/20260218183511.17195-1-pushkarkumarsingh1970@gmail.com/t/#mdd8548b634142f4916e2911f7025e736a4789a07\nProposed extending git repo info to expose additional repository\npath-related values currently accessible via git rev-parse.\nInitiated design discussion regarding path handling and output\nformat, incorporating feedback during iteration.\n\nAdditional Participation:\n\nIn addition to submitting patches, I have:\n*  Reviewed patches from other contributors\n    (1) https://lore.kernel.org/git/CALE2CrTzYbMam_fi5HszSUFVZADE1haLtpBqhUmd1ki9biM2hA@mail.gmail.com/T/#u\n    (2) https://lore.kernel.org/git/20260202134657.15320-1-pushkarkumarsingh1970@gmail.com/T/#u\n    (3) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=C9jMyEVjwMqvh6J2w@mail.gmail.com/\n    (4) https://lore.kernel.org/git/CALE2CrTuZkFm1R3Bb6gFmrN1trr88vdO_7Aw6ycBYvFpWMEEtA@mail.gmail.com/T/#u\n    (5) https://lore.kernel.org/git/CALE2CrSu-JW___Lav0SnLPfwxB8QCRYMKQgsfbXCHrAQSEyDoA@mail.gmail.com/T/#u\n    (6) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com/T/#u\n    (7) https://lore.kernel.org/git/CALE2CrR_Xrei32pc_gJ16mArZPjZ-+bNWWFnsJ3i+OGqbxwPcg@mail.gmail.com/T/#u\n*  Assisted in resolving a git rebase issue on the mailing list\n    (1) https://lore.kernel.org/git/CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=USr5d510SQ@mail.gmail.com/T/#madfc34c4334a7d62baa18b18e3c8fa83600f8455\n*  Studied the original discussions on git repo\n    (1) https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u\n    (2) https://lore.kernel.org/git/20251207190532.67107-1-lucasseikioshiro@gmail.com/T/#u\n    (3) https://lore.kernel.org/git/20260218211845.96009-1-lucasseikioshiro@gmail.com/T/#u\n    (4) https://lore.kernel.org/git/20260203221758.1164434-1-jltobler@gmail.com/T/#u\n*  Examined the implementation in builtin/repo.c\n\n\nThe Plan\n--------\n\nI will be iterating on this project in blocks and with the\nreview-driven approach. By introducing every changes in small,\nlogically isolated patches, I'll ensure clarity, ease-of-review,\nand architectural stability.\n\nFirst I want to cover foundational repository path keys,\nbecause they create instant structural value and more closely fit\nwith existing functionalities of rev-parse.\n\nFor every key proposed or enhancement made, I will:\n\n  - Ensure behavior matches with existing helpers.\n  - Clarify semantics(absolute vs relative paths, edge cases) by\n    discussing on the mailing list before finalizing the behavior.\n  - Add one key (or one closely tied family of keys) per patch.\n  - Add targeted tests covering:\n        * bare repositories\n        * linked worktrees\n        * submodules\n        * shallow clones\n  - Update documentation accordingly.\n\nI will avoid large changes and focus on small, reviewable patches,\ninstead of rapidly expanding features.\n\n\nPath Key Expansion\n------------------\n\nI will incrementally expose selected repository path values\ncurrently accessible via:\n\n  - git rev-parse\n  - git rev-parse --git-path\n\nMy initial focus will be on foundational keys such as:\n\n  path.git-dir\n  path.common-dir\n  path.toplevel\n  path.superproject-working-tree\n\nSubsequent patches may introduce additional --git-path\nequivalents such as:\n\n  path.index-file\n  path.objects-dir\n  path.config-file\n\nEach key will be evaluated individually to ensure clarity,\nnecessity, and consistent semantics.\n\n\nOptional: Category-Based Queries (If Aligned)\n--------------------------------------------\n\nIf agreed upon through mailing list discussion, I will introduce\nexplicit grouped queries, such as:\n\n  git repo info paths\n\nThe expansion will still be deterministic and predefined.\nI'll not be introducing any implicit or dynamic grouping behavior.\n\n\nrepo structure Enhancements\n---------------------------\n\nIf maintainers deem it appropriate maybe I will tackle some \ncarefully scoped improvements to git repo structure.\n\nPotential areas include:\n  - Distribution-oriented metrics, only if aligned with the\n    tool’s long-term direction.\n  - Low-friction structural metrics (e.g., path depth),\n    as long as they do not add excessive traversal cost.\n\nAny such enhancement will be introduced in small,\nstandalone patches, taking performance, maintainability, \nand output stability into account. If scope or review\ntimelines demand, this stage will be delayed.\n\n\nArchitectural Considerations\n----------------------------\n\nWhere appropriate, I will:\n\n  - Prefer explicit repository context over global state.\n  - Avoid duplicating logic already implemented in rev-parse. \n    Where possible, I'll reuse existing helper functions rather \n    than reimplementing path resolution logic.\n  - Preserve conservative output stability.\n\nStructural refactoring will only be undertaken when directly\nrelevant to git repo and supported through review discussion.\n\n\nTimeline\n--------\n\nKeeping Git's iterative and review-driven workflow in mind, I've \ndesigned the timeline to focus on core enhancements in order to \nensure that I can produce meaningful deliverables even if review \ncycles extend.\n\n\nPre-Coding Preparation (Before Official Start)\n\n- Continue participating in git repo discussions.\n- Improve and restrict scope of path key expansion.\n- Confirm semantics for absolute vs relative path handling.\n- Define patch ordering to keep the submissions small\n  and logically independent.\n\n\nCommunity Bonding Period (May)\n\nPrimary objective: finalize scope and ordering.\n\n- Confirm priority list of path keys.\n- Align on output stability expectations.\n- Clarify whether category-based queries are desirable\n  in this cycle or deferred.\n- Identify architectural considerations relevant\n  to builtin/repo.c.\n\nI will get to implementation once the semantics feel reasonably\naligned through mailing list discussion.\n\n\nPhase 1 (Weeks 1–4): Foundational Path Keys\n\nObjective: establish core path parity in git repo info\nwith essential rev-parse values.\n\n* Weeks 1–2:\n  - Submit path.git-dir\n  - Submit path.common-dir\n\n  I'll present these foundational keys early on to keep \n  semantics consistent, and stabilize output expectations.\n\n* Week 3:\n  - Submit path.toplevel\n  - Submit path.superproject-working-tree\n\n  These will provide working-tree inspection coverage to\n  and submodule-aware contexts.\n\n* Week 4:\n  - Submit selected stable --git-path equivalents\n    (e.g., path.index-file, path.objects-dir),\n    introduced incrementally, one per patch.\n\nI'll submit each key independently. When semantics are \nalready aligned, I'll send consecutive patches while\nolder ones will remain pending, which allows a significant \noverlap between submission and iteration.\n\nMidpoint Goal:\n Deliver foundational path keys that are either merged or\n in next, with consensus on semantics.\n\n\nPhase 2 (Weeks 5–8): Additional Path Keys & Refinement\n\n- Finish the remaining agreed --git-path parity keys.\n- Address changes from review cycles of Phase 1.\n- Stabilize behaviour across edge-case environments.\n\nThis phase purposely leaves time for review-guided\niteration without expanding scope.\n\n\nPhase 3 (Weeks 9–10): Optional Enhancements\n\nOnly if Phase 1 and 2 stabilize earlier than expected,\nI'll begin:\n- Introducing the grouped category queries(e.g., info paths),\n  subject to prior agreement.\n- Carefully extending repo structure with one metric \n  at a time.\n\nI’m not going to attempt any bulk metric expansion here.\n\n\nFinal Weeks (Weeks 11–12): Consolidation\n\nOver the last weeks of this program, I will:\n- Address remaining review feedback.\n- Adjust patches if requested or rework them.\n- Finalize documentation.\n- Ensure CI stability and cross-platform behavior.\n\nDuring this time no new features will be introduced.\n\n\nPrioritization Under Constraints\n--------------------------------\n\nConsidering Git’s iterative review process, I have structured the\nproject so that foundational improvements are delivered first.\n\nIf review cycles extend longer than anticipated, my priority will be:\n\n1. Core path parity (path.git-dir, path.common-dir,\n   path.toplevel, path.superproject-working-tree)\n2. Additional agreed --git-path equivalents\n3. Category-based queries\n4. repo structure metric extensions\n\nThis ordering ensures that the most architecturally meaningful\nenhancements are completed even if optional improvements\nmust be deferred.\n\n\nPost-GSoC Continuation\n----------------------\n\nMy involvement in Git is not limited to the GSoC period.\n\nAfter the coding phase, I intend to:\n- Continue refining git repo through incremental improvements.\n- Address follow-up review feedback or deferred enhancements.\n- Participate in reviewing related patches where appropriate.\n- Contribute to ongoing efforts around repository introspection\n  and gradual libification.\n\nOver time, I hope to contribute not only through patches,\nbut also by helping new contributors navigate the mailing\nlist workflow and patch iteration process.\n\nIf given the opportunity in the future, I would be glad to\nsupport mentoring efforts and help the community grow further.\n\n\nAvailability\n------------\n\nMy end-semester examinations conclude on March 28.\nFollowing this, I will not have academic obligations\nduring the GSoC coding period.\n\nThe project is expected to fall within the 175–350 hour\nrange. I am prepared to commit at the higher end of this\nrange.\n\nDuring the official coding phase (approximately 12 weeks),\nI will be available for 30–35 hours per week. This allows\nfor approximately 360–420 hours of focused development time,\ncomfortably covering the expected project scope.\n\nI will also remain active on the mailing list during the\ncommunity bonding period and will use that time to refine\ndesign decisions and prepare patch sequencing.\n\nI do not anticipate any internships, travel, or major\ncommitments that would interfere with this schedule.\n\n\nBlogging:\n---------\n\nFor the past one year I have been writing technical articles \non Medium, mostly related to Git workflows, developer tooling, \nand lessons from working with real codebases.\n\nI will be sharing weekly updates for the GSoC period to document \nprogress and the discussions on these mailing lists for \ntransparency, and more importantly, to help future contributors.\n\nMedium: https://medium.com/@pushkarscripts\n\n\nRisk Assessment and Mitigation\n------------------------------\n\n1. Review Cycle Duration\n\nConsidering Git’s iterative mailing list workflow, existing \npatches might go through several updates before being \naccepted.\n\nMitigation:\n  The project is structured so that foundational path\n  keys are delivered first. Independent patches allow\n  parallel review and refinement.\n\n2. Scope Creep\n\nExpanding both path keys and structure metrics\nmay introduce unintended scope growth.\n\nMitigation:\n  Optional enhancements (categories and additional\n  metrics) are explicitly deferred until foundational\n  work stabilizes.\n\n3. Semantic Ambiguity\n\nPath-related behavior (absolute vs relative,\nworktree interactions, submodules) may require\ncareful alignment.\n\nMitigation:\n  Semantics will be clarified during the bonding\n  period and validated against existing helpers\n  before implementation.\n\n---\n\nThank you for your time and consideration. I look forward\nto contributing further to the project and continuing to\nlearn through the review process.\n\nRegards, \nPushkar Singh\n\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\n\nChanges in v2:\n- Updated status of my recent patch activities.\n- Added recent patch reviews I made in Mailing List.\n- Improved clarity and readability across sections. "},{"id":"539141","messageId":"CAOLa=ZRpRv61Z7bkch53LJjsvZV2T3S+yRKOxYdK6U=oKW10YA@mail.gmail.com","threadId":"65265","inReplyTo":"20260316130431.1318-1-pushkarkumarsingh1970@gmail.com","subject":"Re: [GSoC][RFC v2] Proposal: Improve the new git repo command","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-03-16T18:10:41Z","receivedAt":"2026-03-16T18:10:43Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Pushkar Singh <pushkarkumarsingh1970@gmail.com> writes:\n\nHello Pushkar,\n\nThanks for your proposal\n\n[snip]\n\n\n> The Plan\n> --------\n>\n> I will be iterating on this project in blocks and with the\n> review-driven approach. By introducing every changes in small,\n> logically isolated patches, I'll ensure clarity, ease-of-review,\n> and architectural stability.\n>\n> First I want to cover foundational repository path keys,\n> because they create instant structural value and more closely fit\n> with existing functionalities of rev-parse.\n>\n> For every key proposed or enhancement made, I will:\n>\n>   - Ensure behavior matches with existing helpers.\n\nWhich existing helpers?\n\n>   - Clarify semantics(absolute vs relative paths, edge cases) by\n>     discussing on the mailing list before finalizing the behavior.\n\nIt would be nice if you explained a bit about this, what is the current\ncondition what are your thoughts and what do you plan to implement.\n\n>   - Add one key (or one closely tied family of keys) per patch.\n>   - Add targeted tests covering:\n>         * bare repositories\n>         * linked worktrees\n>         * submodules\n>         * shallow clones\n\nI'd be very interested in what the current test scenario looks like and\nhow we'll improve on top of that.\n\n>   - Update documentation accordingly.\n>\n> I will avoid large changes and focus on small, reviewable patches,\n> instead of rapidly expanding features.\n>\n\nI agree, most often students underestimate the time needed for iterating\nand getting reviews on the mailing list. Having smaller well defined\npatches helps.\n\n>\n> Path Key Expansion\n> ------------------\n>\n> I will incrementally expose selected repository path values\n> currently accessible via:\n>\n>   - git rev-parse\n>   - git rev-parse --git-path\n>\n> My initial focus will be on foundational keys such as:\n>\n>   path.git-dir\n>   path.common-dir\n>   path.toplevel\n>   path.superproject-working-tree\n>\n> Subsequent patches may introduce additional --git-path\n> equivalents such as:\n>\n>   path.index-file\n>   path.objects-dir\n>   path.config-file\n>\n> Each key will be evaluated individually to ensure clarity,\n> necessity, and consistent semantics.\n>\n>\n> Optional: Category-Based Queries (If Aligned)\n> --------------------------------------------\n>\n> If agreed upon through mailing list discussion, I will introduce\n> explicit grouped queries, such as:\n>\n>   git repo info paths\n>\n> The expansion will still be deterministic and predefined.\n> I'll not be introducing any implicit or dynamic grouping behavior.\n>\n>\n> repo structure Enhancements\n> ---------------------------\n>\n> If maintainers deem it appropriate maybe I will tackle some\n> carefully scoped improvements to git repo structure.\n>\n> Potential areas include:\n>   - Distribution-oriented metrics, only if aligned with the\n>     tool’s long-term direction.\n>   - Low-friction structural metrics (e.g., path depth),\n>     as long as they do not add excessive traversal cost.\n>\n> Any such enhancement will be introduced in small,\n> standalone patches, taking performance, maintainability,\n> and output stability into account. If scope or review\n> timelines demand, this stage will be delayed.\n>\n\nI'm curios to know about the timeline and how this plans into it.\nReading along.\n\n>\n> Architectural Considerations\n> ----------------------------\n>\n> Where appropriate, I will:\n>\n>   - Prefer explicit repository context over global state.\n>   - Avoid duplicating logic already implemented in rev-parse.\n>     Where possible, I'll reuse existing helper functions rather\n>     than reimplementing path resolution logic.\n>   - Preserve conservative output stability.\n>\n\nI'm not sure what the last sentence here means.\n\n> Structural refactoring will only be undertaken when directly\n> relevant to git repo and supported through review discussion.\n>\n>\n> Timeline\n> --------\n>\n> Keeping Git's iterative and review-driven workflow in mind, I've\n> designed the timeline to focus on core enhancements in order to\n> ensure that I can produce meaningful deliverables even if review\n> cycles extend.\n>\n>\n> Pre-Coding Preparation (Before Official Start)\n>\n> - Continue participating in git repo discussions.\n> - Improve and restrict scope of path key expansion.\n> - Confirm semantics for absolute vs relative path handling.\n> - Define patch ordering to keep the submissions small\n>   and logically independent.\n>\n>\n> Community Bonding Period (May)\n>\n> Primary objective: finalize scope and ordering.\n>\n> - Confirm priority list of path keys.\n> - Align on output stability expectations.\n> - Clarify whether category-based queries are desirable\n>   in this cycle or deferred.\n\nIn this cycle? IF we do go with category-based queries, isn't that a\ndesign choice which affects all 'git repo info' keys? Would we need to\nspecifically solve for path keys?\n\n> - Identify architectural considerations relevant\n>   to builtin/repo.c.\n>\n\nWhat do you mean by this?\n\n> I will get to implementation once the semantics feel reasonably\n> aligned through mailing list discussion.\n>\n>\n> Phase 1 (Weeks 1–4): Foundational Path Keys\n>\n> Objective: establish core path parity in git repo info\n> with essential rev-parse values.\n>\n> * Weeks 1–2:\n>   - Submit path.git-dir\n>   - Submit path.common-dir\n>\n>   I'll present these foundational keys early on to keep\n>   semantics consistent, and stabilize output expectations.\n>\n> * Week 3:\n>   - Submit path.toplevel\n>   - Submit path.superproject-working-tree\n>\n>   These will provide working-tree inspection coverage to\n>   and submodule-aware contexts.\n>\n> * Week 4:\n>   - Submit selected stable --git-path equivalents\n>     (e.g., path.index-file, path.objects-dir),\n>     introduced incrementally, one per patch.\n>\n> I'll submit each key independently. When semantics are\n> already aligned, I'll send consecutive patches while\n> older ones will remain pending, which allows a significant\n> overlap between submission and iteration.\n>\n> Midpoint Goal:\n>  Deliver foundational path keys that are either merged or\n>  in next, with consensus on semantics.\n>\n>\n> Phase 2 (Weeks 5–8): Additional Path Keys & Refinement\n>\n> - Finish the remaining agreed --git-path parity keys.\n> - Address changes from review cycles of Phase 1.\n> - Stabilize behaviour across edge-case environments.\n>\n> This phase purposely leaves time for review-guided\n> iteration without expanding scope.\n>\n>\n> Phase 3 (Weeks 9–10): Optional Enhancements\n>\n> Only if Phase 1 and 2 stabilize earlier than expected,\n> I'll begin:\n> - Introducing the grouped category queries(e.g., info paths),\n>   subject to prior agreement.\n> - Carefully extending repo structure with one metric\n>   at a time.\n>\n> I’m not going to attempt any bulk metric expansion here.\n>\n>\n> Final Weeks (Weeks 11–12): Consolidation\n>\n> Over the last weeks of this program, I will:\n> - Address remaining review feedback.\n> - Adjust patches if requested or rework them.\n> - Finalize documentation.\n> - Ensure CI stability and cross-platform behavior.\n>\n> During this time no new features will be introduced.\n>\n\nSomething we'd also like to see is if you have other events which might\naffect the timeline, like exams at college. If not, worthwhile to call\nit out.\n\n>\n> Prioritization Under Constraints\n> --------------------------------\n>\n> Considering Git’s iterative review process, I have structured the\n> project so that foundational improvements are delivered first.\n>\n> If review cycles extend longer than anticipated, my priority will be:\n>\n> 1. Core path parity (path.git-dir, path.common-dir,\n>    path.toplevel, path.superproject-working-tree)\n> 2. Additional agreed --git-path equivalents\n> 3. Category-based queries\n> 4. repo structure metric extensions\n>\n> This ordering ensures that the most architecturally meaningful\n> enhancements are completed even if optional improvements\n> must be deferred.\n>\n>\n> Post-GSoC Continuation\n> ----------------------\n>\n> My involvement in Git is not limited to the GSoC period.\n>\n> After the coding phase, I intend to:\n> - Continue refining git repo through incremental improvements.\n> - Address follow-up review feedback or deferred enhancements.\n> - Participate in reviewing related patches where appropriate.\n> - Contribute to ongoing efforts around repository introspection\n>   and gradual libification.\n>\n> Over time, I hope to contribute not only through patches,\n> but also by helping new contributors navigate the mailing\n> list workflow and patch iteration process.\n>\n> If given the opportunity in the future, I would be glad to\n> support mentoring efforts and help the community grow further.\n>\n>\n> Availability\n> ------------\n>\n\nAh, seems like you do go over it.\n\n> My end-semester examinations conclude on March 28.\n> Following this, I will not have academic obligations\n> during the GSoC coding period.\n>\n> The project is expected to fall within the 175–350 hour\n> range. I am prepared to commit at the higher end of this\n> range.\n>\n> During the official coding phase (approximately 12 weeks),\n> I will be available for 30–35 hours per week. This allows\n> for approximately 360–420 hours of focused development time,\n> comfortably covering the expected project scope.\n>\n> I will also remain active on the mailing list during the\n> community bonding period and will use that time to refine\n> design decisions and prepare patch sequencing.\n>\n> I do not anticipate any internships, travel, or major\n> commitments that would interfere with this schedule.\n>\n>\n> Blogging:\n> ---------\n>\n> For the past one year I have been writing technical articles\n> on Medium, mostly related to Git workflows, developer tooling,\n> and lessons from working with real codebases.\n>\n> I will be sharing weekly updates for the GSoC period to document\n> progress and the discussions on these mailing lists for\n> transparency, and more importantly, to help future contributors.\n>\n> Medium: https://medium.com/@pushkarscripts\n>\n>\n> Risk Assessment and Mitigation\n> ------------------------------\n>\n> 1. Review Cycle Duration\n>\n> Considering Git’s iterative mailing list workflow, existing\n> patches might go through several updates before being\n> accepted.\n>\n> Mitigation:\n>   The project is structured so that foundational path\n>   keys are delivered first. Independent patches allow\n>   parallel review and refinement.\n>\n> 2. Scope Creep\n>\n> Expanding both path keys and structure metrics\n> may introduce unintended scope growth.\n>\n> Mitigation:\n>   Optional enhancements (categories and additional\n>   metrics) are explicitly deferred until foundational\n>   work stabilizes.\n>\n> 3. Semantic Ambiguity\n>\n> Path-related behavior (absolute vs relative,\n> worktree interactions, submodules) may require\n> careful alignment.\n>\n> Mitigation:\n>   Semantics will be clarified during the bonding\n>   period and validated against existing helpers\n>   before implementation.\n>\n> ---\n>\n> Thank you for your time and consideration. I look forward\n> to contributing further to the project and continuing to\n> learn through the review process.\n>\n> Regards,\n> Pushkar Singh\n>\n> ---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\n>\n> Changes in v2:\n> - Updated status of my recent patch activities.\n> - Added recent patch reviews I made in Mailing List.\n> - Improved clarity and readability across sections.\n\nRegards,\nKarthik\n"},{"id":"539243","messageId":"CALE2CrSmPs44Pi5=+s0bir1-ti5UR8xOGUMkrGhi1sRjiTwF-Q@mail.gmail.com","threadId":"65265","inReplyTo":"CAOLa=ZRpRv61Z7bkch53LJjsvZV2T3S+yRKOxYdK6U=oKW10YA@mail.gmail.com","subject":"Re: [GSoC][RFC v2] Proposal: Improve the new git repo command","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-03-17T17:20:00Z","receivedAt":"2026-03-17T17:20:15Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Karthik,\nThanks for your review, this was very helpful.\n\n> Which existing helpers?\n\nI was referring to helpers used by git rev-parse and related path\nresolution logic, such as repo_git_pathv() and repo_common_path().\nI’ll make sure to explicitly clarify this and ensure reuse of existing\nhelpers instead of introducing new path handling logic.\n\n> It would be nice if you explained a bit about this, what is the current\n> condition what are your thoughts and what do you plan to implement.\n\nMakes sense. I’ll expand this section to describe the current ambiguity\naround absolute vs relative paths, and outline the approaches being\ndiscussed along with what I plan to follow.\n\n> I'd be very interested in what the current test scenario looks like\n> and how we'll improve on top of that.\n\nGot it. I’ll include the current coverage in t1900-repo-info.sh and\ndescribe how I plan to extend it across different repository setups.\n\n> I'm not sure what the last sentence here means.\n\nUnderstood. I’ll rephrase this to make it more concrete.\n\n> In this cycle? IF we do go with category-based queries, isn't that a\n> design choice which affects all git repo info keys? Would we need to\n> specifically solve for path keys?\n\nThat’s a good point. I’ll clarify this and describe category-based\nqueries as a general design choice rather than something tied only to\npath keys.\n\n> What do you mean by this?\n\nI meant identifying areas in builtin/repo.c where structural changes\nmay be required while adding new fields. I’ll make this more precise.\n\nI’ll incorporate these changes and send a revised version (v3) shortly.\n\nRegards,\nPushkar\n"},{"id":"539289","messageId":"20260318134202.23472-1-pushkarkumarsingh1970@gmail.com","threadId":"65265","inReplyTo":"20260316130431.1318-1-pushkarkumarsingh1970@gmail.com","subject":"[GSoC][RFC v3] Proposal: Improve the new git repo command","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-03-18T13:42:02Z","receivedAt":"2026-03-18T13:42:13Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Everyone,\nThis is the third version of my proposal for \"Improve the new git repo command\" in Google Summer of Code 2026, updated based on Karthik’s feedback.\n\nThe Doc version:\nhttps://docs.google.com/document/d/1HM1HNQqUrGdqFdUppc02BTmPuwXC2ozCw9mLrbaVUHc/edit?usp=sharing\n\nI'd appreciate any feedback on this.\n\nThanks,\nPushkar\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\n\nGSoC 2026 @ Git | Pushkar Singh\nImprove the new git repo command\n---------------------------------------------------\n\n\nPersonal Information:\n---------------------\nName: Pushkar Singh\nE-mail: pushkarkumarsingh1970@gmail.com\n\nEducation: XIM University, Bhubaneswar, Odisha, India\nYear: II/III\nDegree: Bachelors in Computer Science & Engineering\n\nTime-Zone: UTC + 5:30 (IST)\n\nPersonal page: https://pushkarscripts.com/\nBlog: https://medium.com/@pushkarscripts/\nGitHub: https://github.com/pushkarscripts/\n\n\nPre-GSOC:\n---------\n\nI began exploring Git’s codebase by studying its documentation, \nreviewing prior mailing list discussions, and building Git from \nsource. \nI focused on understanding the test framework, patch submission \nworkflow using git send-email, versioned patch iteration, and \nthe review culture on the mailing list.\n\nAfter becoming familiar with the contribution process, I started \nsubmitting patches.\n\n\nContributions to Git (Chronological Order):\n-------------------------------------------\n\n* [PATCH v4] t1300: use test helpers instead of test builtins\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260104194812.15134-1-pushkarkumarsingh1970@gmail.com/t/#u\nThis patch is my first contribution to fulfill microproject \ncriteria. It replaces legacy test -f and test -h checks with \ntest_path_is_file and test_path_is_symlink in the test suite.\n\n* [PATCH v2] t1410: use test helpers in reflog rewind test\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260111191525.17087-1-pushkarkumarsingh1970@gmail.com/t/#u\nReplaced raw file existence checks in the reflog rewind test \nwith test_path_is_file and test_path_is_missing. The subject \nand commit message were refined in v2 following review feedback.\n\n* [PATCH] Documentation/config: fix replacement for --get-urlmatch\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260115110832.15315-1-pushkarkumarsingh1970@gmail.com/T/#u\n    Related Bug Report: https://lore.kernel.org/git/CAGJzqs=0Zr2iqsTUZdjdwpbtaS7kuBOf=E_XT=vbdfyNTKkjNQ@mail.gmail.com/t/#u\nCorrected documentation that incorrectly suggested combining \n--url with --all for --get-urlmatch. Verified the behavior \nagainst the implementation and updated the documentation \naccordingly.\n\n* [PATCH v3] path: refactor normalize_path_copy_len for clarity\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260221110511.1592-2-pushkarkumarsingh1970@gmail.com/t/#u\nProposed a refactor of normalize_path_copy_len to improve \nclarity while preserving existing control flow. The discussion\nfocused on maintaining readability and minimizing structural \nchanges.\n\n* [PATCH v4] subtree: validate --prefix against commit in split\n    Status: Merged into master\n    Thread: https://lore.kernel.org/git/20260203164815.68258-2-pushkarkumarsingh1970@gmail.com/T/#u\n    Related Bug Report: https://lore.kernel.org/git/CAFePT4xDGegpEFuFemCXsH890E2WXnG3JzUZeiLi9KW8D8beOg@mail.gmail.com/T/#u\nUpdated git subtree split to validate --prefix against the \nspecified commit rather than the working tree. The change \naddresses a mailing list report where --prefix was incorrectly \nvalidated against the current working directory instead of the \ngiven revision. Added regression tests and revised the patch \nacross four versions following review and CI feedback before \nintegration into next.\n\n* [RFC] git repo info: expose repository paths\n    Status: WIP, Under discussion\n    Thread: https://lore.kernel.org/git/20260218183511.17195-1-pushkarkumarsingh1970@gmail.com/t/#mdd8548b634142f4916e2911f7025e736a4789a07\nProposed extending git repo info to expose additional repository\npath-related values currently accessible via git rev-parse.\nInitiated design discussion regarding path handling and output\nformat, incorporating feedback during iteration.\n\nAdditional Participation:\n\nIn addition to submitting patches, I have:\n*  Reviewed patches from other contributors\n    (1) https://lore.kernel.org/git/CALE2CrTzYbMam_fi5HszSUFVZADE1haLtpBqhUmd1ki9biM2hA@mail.gmail.com/T/#u\n    (2) https://lore.kernel.org/git/20260202134657.15320-1-pushkarkumarsingh1970@gmail.com/T/#u\n    (3) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=C9jMyEVjwMqvh6J2w@mail.gmail.com/\n    (4) https://lore.kernel.org/git/CALE2CrTuZkFm1R3Bb6gFmrN1trr88vdO_7Aw6ycBYvFpWMEEtA@mail.gmail.com/T/#u\n    (5) https://lore.kernel.org/git/CALE2CrSu-JW___Lav0SnLPfwxB8QCRYMKQgsfbXCHrAQSEyDoA@mail.gmail.com/T/#u\n    (6) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com/T/#u\n    (7) https://lore.kernel.org/git/CALE2CrR_Xrei32pc_gJ16mArZPjZ-+bNWWFnsJ3i+OGqbxwPcg@mail.gmail.com/T/#u\n*  Assisted in resolving a git rebase issue on the mailing list\n    (1) https://lore.kernel.org/git/CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=USr5d510SQ@mail.gmail.com/T/#madfc34c4334a7d62baa18b18e3c8fa83600f8455\n*  Studied the original discussions on git repo\n    (1) https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u\n    (2) https://lore.kernel.org/git/20251207190532.67107-1-lucasseikioshiro@gmail.com/T/#u\n    (3) https://lore.kernel.org/git/20260218211845.96009-1-lucasseikioshiro@gmail.com/T/#u\n    (4) https://lore.kernel.org/git/20260203221758.1164434-1-jltobler@gmail.com/T/#u\n*  Examined the implementation in builtin/repo.c\n\n\nThe Plan\n--------\n\nI will be iterating on this project in blocks and with the\nreview-driven approach. By introducing every changes in small,\nlogically isolated patches, I'll ensure clarity, ease-of-review,\nand architectural stability.\n\nFirst I want to cover foundational repository path keys,\nbecause they create instant structural value and more closely fit\nwith existing functionalities of rev-parse.\n\nFor every key proposed or enhancement made, I will:\n\n  - Ensure behavior matches helpers currently used in git rev-parse, \n    such as repo_get_work_tree(), repo_get_common_dir(),\n    repo_get_git_dir(), and related helpers such as repo_git_path*(), \n    along with print_path() for formatting behavior.\n  - Currently, git rev-parse outputs paths based on options like\n    --path-format and also varies depending on the specific command\n    (e.g., --git-dir, --show-toplevel). This can lead to slightly\n    different behaviors across commands. The expected behavior for\n    git repo info is still under discussion (e.g., whether paths\n    should always be absolute, or configurable).\n    During the bonding period, I plan to:\n      - Review existing discussions on path formatting\n      - Align on a consistent default behavior\n      - Ensure compatibility with existing expectations from rev-parse \n  - Category-based queries represent a broader design decision affecting \n    the overall interface of git repo info, not just path-related fields. \n    I will evaluate their impact and ensure they integrate cleanly with \n    existing key-based querying before proposing an implementation.\n  - Add one key (or one closely tied family of keys) per patch.\n  - The current test coverage in t1900-repo-info.sh focuses on:\n      - Basic key-value retrieval\n      - Output formats (lines, nul)\n      - Error handling for invalid keys, formats, and flag combinations.\n      - Repository configurations such as bare repositories, shallow \n        clones, object format, and reference format.\n    However, it does not yet cover:\n      - Path-related keys (e.g., path.git-dir, path.toplevel)\n      - More complex repository setups such as linked worktrees and submodules\n      - Edge cases involving relative vs absolute path behavior\n    I plan to extend the test suite to include these scenarios, ensuring \n    consistent behavior across different repository layouts while \n    preserving existing invariants.\n  - Update documentation accordingly.\n\nI will avoid large changes and focus on small, reviewable patches,\ninstead of rapidly expanding features.\n\n\nPath Key Expansion\n------------------\n\nI will incrementally expose selected repository path values\ncurrently accessible via:\n\n  - git rev-parse\n  - git rev-parse --git-path\n\nMy initial focus will be on foundational keys such as:\n\n  path.git-dir\n  path.common-dir\n  path.toplevel\n  path.superproject-working-tree\n\nSubsequent patches may introduce additional --git-path\nequivalents such as:\n\n  path.index-file\n  path.objects-dir\n  path.config-file\n\nEach key will be evaluated individually to ensure clarity,\nnecessity, and consistent semantics.\n\n\nrepo structure Enhancements\n---------------------------\n\nIf maintainers deem it appropriate maybe I will tackle some \ncarefully scoped improvements to git repo structure.\n\nPotential areas include:\n  - Distribution-oriented metrics, only if aligned with the\n    tool’s long-term direction.\n  - Low-friction structural metrics (e.g., path depth),\n    as long as they do not add excessive traversal cost.\n\nAny such enhancement will be introduced in small,\nstandalone patches, taking performance, maintainability, \nand output stability into account. \n\nIf scope or review timelines demand, I can push this work to \nlater stages of GSoC or continue it after GSoC.\n\n\nArchitectural Considerations\n----------------------------\n\nWhere appropriate, I will:\n\n  - Prefer explicit repository context over global state.\n  - Avoid duplicating logic already implemented in rev-parse. \n    Where possible, I'll reuse existing helper functions rather \n    than reimplementing path resolution logic.\n  - Ensure that newly added fields do not change existing output \n    behavior (ordering, formats, or flag behavior), and remain \n    consistent with Git’s scripting-friendly output.\n\nStructural refactoring will only be undertaken when directly\nrelevant to git repo and supported through review discussion.\n\n\nTimeline\n--------\n\nKeeping Git's iterative and review-driven workflow in mind, I've \ndesigned the timeline to focus on core enhancements in order to \nensure that I can produce meaningful deliverables even if review \ncycles extend.\n\n\nPre-Coding Preparation (Before Official Start)\n\n- Continue participating in git repo discussions.\n- Improve and restrict scope of path key expansion.\n- Confirm semantics for absolute vs relative path handling.\n- Define patch ordering to keep the submissions small\n  and logically independent.\n\n\nCommunity Bonding Period (May)\n\nPrimary objective: finalize scope and ordering.\n\n- Confirm priority list of path keys.\n- Align on output stability expectations.\n- Evaluate category-based queries as a broader interface design \n  decision affecting all keys, and determine whether they should \n  be introduced in this cycle or deferred.\n- Identify specific areas in builtin/repo.c where new fields \n  can be integrated cleanly, reusing existing helpers and \n  maintaining consistency with the current key-to-field dispatch \n  structure.\n\nI will get to implementation once the semantics feel reasonably\naligned through mailing list discussion.\n\n\nPhase 1 (Weeks 1–4): Foundational Path Keys\n\nObjective: establish core path parity in git repo info\nwith essential rev-parse values.\n\n* Weeks 1–2:\n  - Submit path.git-dir\n  - Submit path.common-dir\n\n  I'll present these foundational keys early on to keep \n  semantics consistent, and stabilize output expectations.\n\n* Week 3:\n  - Submit path.toplevel\n  - Submit path.superproject-working-tree\n\n  These will provide working-tree inspection coverage and\n  support submodule-aware contexts.\n\n* Week 4:\n  - Submit selected stable --git-path equivalents\n    (e.g., path.index-file, path.objects-dir),\n    introduced incrementally, one per patch.\n\nI'll submit each key independently. When semantics are \nalready aligned, I'll send consecutive patches while\nolder ones will remain pending, which allows a significant \noverlap between submission and iteration.\n\nMidpoint Goal:\n Deliver foundational path keys that are either merged or\n in next, with consensus on semantics.\n\n\nPhase 2 (Weeks 5–8): Additional Path Keys & Refinement\n\n- Finish the remaining agreed --git-path parity keys.\n- Address changes from review cycles of Phase 1.\n- Stabilize behaviour across edge-case environments.\n\nThis phase purposely leaves time for review-guided\niteration without expanding scope.\n\n\nPhase 3 (Weeks 9–10): Optional Enhancements\n\nOnly if Phase 1 and 2 stabilize earlier than expected,\nI'll begin:\n- Introducing the grouped category queries(e.g., info paths),\n  subject to prior agreement.\n- Carefully extending repo structure with one metric \n  at a time.\n\nI’m not going to attempt any bulk metric expansion here.\n\n\nFinal Weeks (Weeks 11–12): Consolidation\n\nOver the last weeks of this program, I will:\n- Address remaining review feedback.\n- Adjust patches if requested or rework them.\n- Finalize documentation.\n- Ensure CI stability and cross-platform behavior.\n\nDuring this time no new features will be introduced.\n\n\nPrioritization Under Constraints\n--------------------------------\n\nConsidering Git’s iterative review process, I have structured the\nproject so that foundational improvements are delivered first.\n\nIf review cycles extend longer than anticipated, my priority will be:\n\n1. Core path parity (path.git-dir, path.common-dir,\n   path.toplevel, path.superproject-working-tree)\n2. Additional agreed --git-path equivalents\n3. Category-based queries\n4. repo structure metric extensions\n\nThis ordering ensures that the most architecturally meaningful\nenhancements are completed even if optional improvements\nmust be deferred.\n\n\nPost-GSoC Continuation\n----------------------\n\nMy involvement in Git is not limited to the GSoC period.\n\nAfter the coding phase, I intend to:\n- Continue refining git repo through incremental improvements.\n- Address follow-up review feedback or deferred enhancements.\n- Participate in reviewing related patches where appropriate.\n- Contribute to ongoing efforts around repository introspection\n  and gradual libification.\n\nOver time, I hope to contribute not only through patches,\nbut also by helping new contributors navigate the mailing\nlist workflow and patch iteration process.\n\nIf given the opportunity in the future, I would be glad to\nsupport mentoring efforts and help the community grow further.\n\n\nAvailability\n------------\n\nMy end-semester examinations conclude on March 28.\nFollowing this, I will not have academic obligations\nduring the GSoC coding period.\n\nThe project is expected to fall within the 175–350 hour\nrange. I am prepared to commit at the higher end of this\nrange.\n\nDuring the official coding phase (approximately 12 weeks),\nI will be available for 30–35 hours per week. This allows\nfor approximately 360–420 hours of focused development time,\ncomfortably covering the expected project scope.\n\nI will also remain active on the mailing list during the\ncommunity bonding period and will use that time to refine\ndesign decisions and prepare patch sequencing.\n\nI do not anticipate any internships, travel, or major\ncommitments that would interfere with this schedule.\n\n\nBlogging:\n---------\n\nFor the past one year I have been writing technical articles \non Medium, mostly related to Git workflows, developer tooling, \nand lessons from working with real codebases.\n\nI will be sharing weekly updates for the GSoC period to document \nprogress and the discussions on these mailing lists for \ntransparency, and more importantly, to help future contributors.\n\nMedium: https://medium.com/@pushkarscripts\n\n\nRisk Assessment and Mitigation\n------------------------------\n\n1. Review Cycle Duration\n\nConsidering Git’s iterative mailing list workflow, existing \npatches might go through several updates before being \naccepted.\n\nMitigation:\n  The project is structured so that foundational path\n  keys are delivered first. Independent patches allow\n  parallel review and refinement.\n\n2. Scope Creep\n\nExpanding both path keys and structure metrics\nmay introduce unintended scope growth.\n\nMitigation:\n  Optional enhancements (categories and additional\n  metrics) are explicitly deferred until foundational\n  work stabilizes.\n\n3. Semantic Ambiguity\n\nPath-related behavior (absolute vs relative,\nworktree interactions, submodules) may require\ncareful alignment.\n\nMitigation:\n  Semantics will be clarified during the bonding\n  period and validated against existing helpers\n  before implementation.\n\n---\n\nThank you for your time and consideration. I look forward\nto contributing further to the project and continuing to\nlearn through the review process.\n\nRegards, \nPushkar Singh\n\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\n\nChanges in v3:\n- Clarified which existing helpers will be reused for path handling\n- Expanded discussion on path semantics (absolute vs relative)\n- Added details on current test coverage and planned improvements\n- Clarified expectations around output behavior\n- Reworked category-based queries as a broader design decision\n- Improved clarity in architectural sections "}]}