{"thread":{"id":"65127","subject":"[RFC][GSoC 2026] Proposal: Improve the new git repo command","startedAt":"2026-03-03T14:07:42Z","lastAt":"2026-03-03T14:07:42Z","messageCount":1,"participants":["Pushkar Singh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537669","messageId":"20260303140732.16886-1-pushkarkumarsingh1970@gmail.com","threadId":"65127","inReplyTo":null,"subject":"[RFC][GSoC 2026] Proposal: Improve the new git repo command","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-03-03T14:07:32Z","receivedAt":"2026-03-03T14:07:42Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Everyone,\nI would like to share my proposal for \"Improve the new git repo command\" under GSoC 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 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 \nfrom source. \n\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 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: 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\n* [PATCH v3] path: refactor normalize_path_copy_len for clarity\n    Status: Merged into next\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\nAdditional Participation:\n\nIn addition to submitting patches, I have:\n* Reviewed patches from other contributors\n    (1) https://lore.kernel.org/git/20260202134657.15320-1-pushkarkumarsingh1970@gmail.com/T/#u\n    (2) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=C9jMyEVjwMqvh6J2w@mail.gmail.com/\n    (3) https://lore.kernel.org/git/CALE2CrTuZkFm1R3Bb6gFmrN1trr88vdO_7Aw6ycBYvFpWMEEtA@mail.gmail.com/T/#u\n    (4) https://lore.kernel.org/git/CALE2CrSu-JW___Lav0SnLPfwxB8QCRYMKQgsfbXCHrAQSEyDoA@mail.gmail.com/T/#u\n    (5) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com/T/#u\n    (6) 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 plan to approach this project incrementally, following Git’s\nreview-driven workflow. I will introduce changes in small, \nlogically isolated patches to keep review manageable and avoid\nunintended side effects.\n\nExtensions to git repo will be introduced incrementally and\nonly after review consensus on preceding changes.\n\nI will begin by focusing on foundational repository path keys,\nas they provide immediate structural value and align closely\nwith existing rev-parse functionality.\n\nFor each proposed key or enhancement, I will:\n\n  - Confirm exact behavioral parity with existing helpers.\n  - Clarify semantics (absolute vs relative paths, edge cases)\n    through mailing list discussion before finalizing behavior.\n  - Introduce one key (or one tightly related group) per patch.\n  - Add targeted tests covering:\n        * bare repositories\n        * linked worktrees\n        * submodules\n        * shallow clones\n  - Update documentation accordingly.\n\nBulk additions will be avoided. The goal is steady maturation,\nnot rapid feature expansion.\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\nThe initial focus will be on a small set of foundational keys,\nselected in coordination with maintainers, beginning with \npath.git-dir and path.common-dir. Additional keys will only be\nintroduced after review consensus.\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 maintainers consider it useful, I may introduce explicit,\ndeterministic grouped queries such as:\n\n  git repo info paths\n\nThis will only be attempted after core path parity stabilizes,\nand only if consensus exists. No implicit behavior will be added.\n\n\nArchitectural Considerations\n----------------------------\n\nSince git repo info is intended as a plumbing command,\npredictability and explicitness will be prioritized over\nconvenience defaults. The command should return only what\nis explicitly requested, avoiding implicit behavior that\nmay affect scripts.\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 reimplement path resolution logic.\n  - Maintain stable and predictable output for users and tooling.\n\nStructural refactoring will only be undertaken when directly\nrelevant to git repo and supported through review discussion.\n\n\nTimeline\n--------\n\nThe timeline below reflects Git’s iterative, review-driven workflow.\nFoundational improvements are prioritized to ensure meaningful\ndeliverables even if review cycles extend.\n\n\nPre-Coding Preparation (Before Official Start)\n\n- Continue participating in git repo discussions.\n- Refine and narrow scope of path key expansion.\n- Confirm semantics for absolute vs relative path handling.\n- Define patch ordering to keep 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\nImplementation will follow once semantics are 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  These foundational keys will be introduced early to\n  validate semantics and stabilize output expectations.\n\n* Week 3:\n  - Submit path.toplevel\n  - Submit path.superproject-working-tree\n\n  These additions will extend coverage to working-tree\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\nEach key will be submitted independently. Subsequent \npatches will be sent after consensus on earlier changes\nis reasonably established, enabling overlap between \nsubmission 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- Complete remaining agreed-upon --git-path parity keys.\n- Address review-driven adjustments from Phase 1.\n- Stabilize behaviour across edge-case environments.\n\nThis phase intentionally allows time for review-driven\niteration without expanding scope.\n\n\nPhase 3 (Weeks 9–10): Refinement and Stability\n\n- Improve tests for edge cases discovered during review.\n- Revisit earlier patches if requested.\n\n\nFinal Weeks (Weeks 11–12): Consolidation\n\n- Finalize remaining review iterations.\n- Refine or restructure patches if requested.\n- Finalize documentation.\n- Ensure CI stability and cross-platform behavior.\n\nNo new features will be introduced during this period.\n\n\nPrioritization Under Constraints\n--------------------------------\n\nGiven 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, 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\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\nI have been writing technical articles on Medium for over a \nyear, primarily focused on Git workflows, developer tooling,\nand lessons from working with real codebases.\n\nDuring the GSoC period, I plan to publish bi-weekly updates\ndocumenting progress and mailing list discussions to maintain\ntransparency and assist future contributors.\n\nMedium: https://medium.com/@pushkarscripts\n\n\nRisk Assessment and Mitigation\n------------------------------\n\n1. Review Cycle Duration\n\nGiven Git’s iterative mailing list workflow,\npatches may require multiple revisions before acceptance.\n\nTo mitigate this, I have structured the project so that \nfoundational path keys are delivered first.\n\nTo reduce review friction, patches will be small, logically\nisolated, and submitted only after validating behavior against\nexisting helpers.\n\n2. Scope Creep\n\nExpanding beyond agreed path parity work may \nintroduce 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 for reviewing this proposal.\nI look forward to contributing further to the project \nand continuing to learn through the review process.\n\nRegards,  \nPushkar Singh\n"}]}