* [RFC][GSoC 2026] Proposal: Improve the new git repo command
@ 2026-03-03 14:07 Pushkar Singh
0 siblings, 0 replies; only message in thread
From: Pushkar Singh @ 2026-03-03 14:07 UTC (permalink / raw)
To: git
Cc: lucasseikioshiro, jltobler, karthik.188, siddharthasthana31,
ayu.chandekar, peff, gitster
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 15290 bytes --]
Hi Everyone,
I would like to share my proposal for "Improve the new git repo command" under GSoC 2026.
The Doc version:
https://docs.google.com/document/d/1HM1HNQqUrGdqFdUppc02BTmPuwXC2ozCw9mLrbaVUHc/edit?usp=sharing
I'd appreciate any feedback on this.
Thanks,
Pushkar
---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<
GSoC 2026 @ Git | Pushkar Singh
Improve the new git repo command
---------------------------------------------------
Personal Information:
---------------------
Name: Pushkar Singh
E-mail: pushkarkumarsingh1970@gmail•com
Education: XIM University, Bhubaneswar, Odisha, India
Year: II/III
Degree: Bachelors in Computer Engineering
Time-Zone: UTC + 5:30 (IST)
Personal page: https://pushkarscripts.com/
Blog: https://medium.com/@pushkarscripts/
GitHub: https://github.com/pushkarscripts/
Pre-GSOC:
---------
I began exploring Git’s codebase by studying its documentation,
reviewing prior mailing list discussions, and building Git
from source.
I focused on understanding the test framework, patch submission
workflow using git send-email, versioned patch iteration, and
the review culture on the mailing list.
After becoming familiar with the contribution process, I started
submitting patches.
Contributions to Git (Chronological Order):
-------------------------------------------
* [PATCH v4] t1300: use test helpers instead of test builtins
Status: Merged into master
Thread: https://lore.kernel.org/git/20260104194812.15134-1-pushkarkumarsingh1970@gmail.com/t/#u
This patch is my first contribution to fulfill microproject
criteria. It replaces legacy test -f and test -h checks with
test_path_is_file and test_path_is_symlink in the test suite.
* [PATCH v2] t1410: use test helpers in reflog rewind test
Status: Merged into master
Thread: https://lore.kernel.org/git/20260111191525.17087-1-pushkarkumarsingh1970@gmail.com/t/#u
Replaced raw file existence checks in the reflog rewind test
with test_path_is_file and test_path_is_missing. The subject
and commit message were refined in v2 following review feedback.
* [PATCH] Documentation/config: fix replacement for --get-urlmatch
Status: Merged into master
Thread: https://lore.kernel.org/git/20260115110832.15315-1-pushkarkumarsingh1970@gmail.com/T/#u
Related Bug Report: https://lore.kernel.org/git/CAGJzqs=0Zr2iqsTUZdjdwpbtaS7kuBOf=E_XT=vbdfyNTKkjNQ@mail.gmail.com/t/#u
Corrected documentation that incorrectly suggested combining
--url with --all for --get-urlmatch. Verified the behavior
against the implementation and updated the documentation
accordingly.
* [PATCH v4] subtree: validate --prefix against commit in split
Status: Merged into master
Thread: https://lore.kernel.org/git/20260203164815.68258-2-pushkarkumarsingh1970@gmail.com/T/#u
Related Bug Report: https://lore.kernel.org/git/CAFePT4xDGegpEFuFemCXsH890E2WXnG3JzUZeiLi9KW8D8beOg@mail.gmail.com/T/#u
Updated git subtree split to validate --prefix against the
specified commit rather than the working tree. The change
addresses a mailing list report where --prefix was incorrectly
validated against the current working directory instead of the
given revision. Added regression tests and revised the patch
across four versions following review and CI feedback before
integration into next.
* [RFC] git repo info: expose repository paths
Status: Under discussion
Thread: https://lore.kernel.org/git/20260218183511.17195-1-pushkarkumarsingh1970@gmail.com/t/#mdd8548b634142f4916e2911f7025e736a4789a07
Proposed extending git repo info to expose additional repository
path-related values currently accessible via git rev-parse.
Initiated design discussion regarding path handling and output
format, incorporating feedback during iteration.
* [PATCH v3] path: refactor normalize_path_copy_len for clarity
Status: Merged into next
Thread: https://lore.kernel.org/git/20260221110511.1592-2-pushkarkumarsingh1970@gmail.com/t/#u
Proposed a refactor of normalize_path_copy_len to improve
clarity while preserving existing control flow. The discussion
focused on maintaining readability and minimizing structural
changes.
Additional Participation:
In addition to submitting patches, I have:
* Reviewed patches from other contributors
(1) https://lore.kernel.org/git/20260202134657.15320-1-pushkarkumarsingh1970@gmail.com/T/#u
(2) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=C9jMyEVjwMqvh6J2w@mail.gmail.com/
(3) https://lore.kernel.org/git/CALE2CrTuZkFm1R3Bb6gFmrN1trr88vdO_7Aw6ycBYvFpWMEEtA@mail.gmail.com/T/#u
(4) https://lore.kernel.org/git/CALE2CrSu-JW___Lav0SnLPfwxB8QCRYMKQgsfbXCHrAQSEyDoA@mail.gmail.com/T/#u
(5) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com/T/#u
(6) https://lore.kernel.org/git/CALE2CrR_Xrei32pc_gJ16mArZPjZ-+bNWWFnsJ3i+OGqbxwPcg@mail.gmail.com/T/#u
* Assisted in resolving a git rebase issue on the mailing list
(1) https://lore.kernel.org/git/CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=USr5d510SQ@mail.gmail.com/T/#madfc34c4334a7d62baa18b18e3c8fa83600f8455
* Studied the original discussions on git repo
(1) https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u
(2) https://lore.kernel.org/git/20251207190532.67107-1-lucasseikioshiro@gmail.com/T/#u
(3) https://lore.kernel.org/git/20260218211845.96009-1-lucasseikioshiro@gmail.com/T/#u
(4) https://lore.kernel.org/git/20260203221758.1164434-1-jltobler@gmail.com/T/#u
* Examined the implementation in builtin/repo.c
The Plan
--------
I plan to approach this project incrementally, following Git’s
review-driven workflow. I will introduce changes in small,
logically isolated patches to keep review manageable and avoid
unintended side effects.
Extensions to git repo will be introduced incrementally and
only after review consensus on preceding changes.
I will begin by focusing on foundational repository path keys,
as they provide immediate structural value and align closely
with existing rev-parse functionality.
For each proposed key or enhancement, I will:
- Confirm exact behavioral parity with existing helpers.
- Clarify semantics (absolute vs relative paths, edge cases)
through mailing list discussion before finalizing behavior.
- Introduce one key (or one tightly related group) per patch.
- Add targeted tests covering:
* bare repositories
* linked worktrees
* submodules
* shallow clones
- Update documentation accordingly.
Bulk additions will be avoided. The goal is steady maturation,
not rapid feature expansion.
Path Key Expansion
------------------
I will incrementally expose selected repository path values
currently accessible via:
- git rev-parse
- git rev-parse --git-path
The initial focus will be on a small set of foundational keys,
selected in coordination with maintainers, beginning with
path.git-dir and path.common-dir. Additional keys will only be
introduced after review consensus.
Each key will be evaluated individually to ensure clarity,
necessity, and consistent semantics.
Optional: Category-Based Queries (If Aligned)
--------------------------------------------
If maintainers consider it useful, I may introduce explicit,
deterministic grouped queries such as:
git repo info paths
This will only be attempted after core path parity stabilizes,
and only if consensus exists. No implicit behavior will be added.
Architectural Considerations
----------------------------
Since git repo info is intended as a plumbing command,
predictability and explicitness will be prioritized over
convenience defaults. The command should return only what
is explicitly requested, avoiding implicit behavior that
may affect scripts.
Where appropriate, I will:
- Prefer explicit repository context over global state.
- Avoid duplicating logic already implemented in rev-parse.
Where possible, I'll reuse existing helper functions rather
than reimplement path resolution logic.
- Maintain stable and predictable output for users and tooling.
Structural refactoring will only be undertaken when directly
relevant to git repo and supported through review discussion.
Timeline
--------
The timeline below reflects Git’s iterative, review-driven workflow.
Foundational improvements are prioritized to ensure meaningful
deliverables even if review cycles extend.
Pre-Coding Preparation (Before Official Start)
- Continue participating in git repo discussions.
- Refine and narrow scope of path key expansion.
- Confirm semantics for absolute vs relative path handling.
- Define patch ordering to keep submissions small
and logically independent.
Community Bonding Period (May)
Primary objective: finalize scope and ordering.
- Confirm priority list of path keys.
- Align on output stability expectations.
- Clarify whether category-based queries are desirable
in this cycle or deferred.
- Identify architectural considerations relevant
to builtin/repo.c.
Implementation will follow once semantics are reasonably
aligned through mailing list discussion.
Phase 1 (Weeks 1–4): Foundational Path Keys
Objective: establish core path parity in git repo info
with essential rev-parse values.
* Weeks 1–2:
- Submit path.git-dir
- Submit path.common-dir
These foundational keys will be introduced early to
validate semantics and stabilize output expectations.
* Week 3:
- Submit path.toplevel
- Submit path.superproject-working-tree
These additions will extend coverage to working-tree
and submodule-aware contexts.
* Week 4:
- Submit selected stable --git-path equivalents
(e.g., path.index-file, path.objects-dir),
introduced incrementally, one per patch.
Each key will be submitted independently. Subsequent
patches will be sent after consensus on earlier changes
is reasonably established, enabling overlap between
submission and iteration.
Midpoint Goal:
Deliver foundational path keys that are either merged or
in next, with consensus on semantics.
Phase 2 (Weeks 5–8): Additional Path Keys & Refinement
- Complete remaining agreed-upon --git-path parity keys.
- Address review-driven adjustments from Phase 1.
- Stabilize behaviour across edge-case environments.
This phase intentionally allows time for review-driven
iteration without expanding scope.
Phase 3 (Weeks 9–10): Refinement and Stability
- Improve tests for edge cases discovered during review.
- Revisit earlier patches if requested.
Final Weeks (Weeks 11–12): Consolidation
- Finalize remaining review iterations.
- Refine or restructure patches if requested.
- Finalize documentation.
- Ensure CI stability and cross-platform behavior.
No new features will be introduced during this period.
Prioritization Under Constraints
--------------------------------
Given Git’s iterative review process, I have structured the
project so that foundational improvements are delivered first.
If review cycles extend longer than anticipated, priority will be:
1. Core path parity (path.git-dir, path.common-dir,
path.toplevel, path.superproject-working-tree)
2. Additional agreed --git-path equivalents
3. Category-based queries
This ordering ensures that the most architecturally meaningful
enhancements are completed even if optional improvements
must be deferred.
Post-GSoC Continuation
----------------------
My involvement in Git is not limited to the GSoC period.
After the coding phase, I intend to:
- Continue refining git repo through incremental improvements.
- Address follow-up review feedback or deferred enhancements.
- Participate in reviewing related patches where appropriate.
- Contribute to ongoing efforts around repository introspection
and gradual libification.
Over time, I hope to contribute not only through patches,
but also by helping new contributors navigate the mailing
list workflow and patch iteration process.
If given the opportunity in the future, I would be glad to
support mentoring efforts and help the community grow further.
Availability
------------
My end-semester examinations conclude on March 28.
Following this, I will not have academic obligations
during the GSoC coding period.
The project is expected to fall within the 175–350 hour
range. I am prepared to commit at the higher end of this
range.
During the official coding phase (approximately 12 weeks),
I will be available for 30–35 hours per week. This allows
for approximately 360–420 hours of focused development time,
comfortably covering the expected project scope.
I will also remain active on the mailing list during the
community bonding period and will use that time to refine
design decisions and prepare patch sequencing.
I do not anticipate any internships, travel, or major
commitments that would interfere with this schedule.
Blogging:
---------
I have been writing technical articles on Medium for over a
year, primarily focused on Git workflows, developer tooling,
and lessons from working with real codebases.
During the GSoC period, I plan to publish bi-weekly updates
documenting progress and mailing list discussions to maintain
transparency and assist future contributors.
Medium: https://medium.com/@pushkarscripts
Risk Assessment and Mitigation
------------------------------
1. Review Cycle Duration
Given Git’s iterative mailing list workflow,
patches may require multiple revisions before acceptance.
To mitigate this, I have structured the project so that
foundational path keys are delivered first.
To reduce review friction, patches will be small, logically
isolated, and submitted only after validating behavior against
existing helpers.
2. Scope Creep
Expanding beyond agreed path parity work may
introduce unintended scope growth.
Mitigation:
Optional enhancements (categories and additional
metrics) are explicitly deferred until foundational
work stabilizes.
3. Semantic Ambiguity
Path-related behavior (absolute vs relative,
worktree interactions, submodules) may require
careful alignment.
Mitigation:
Semantics will be clarified during the bonding
period and validated against existing helpers
before implementation.
---
Thank you for your time and for reviewing this proposal.
I look forward to contributing further to the project
and continuing to learn through the review process.
Regards,
Pushkar Singh
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-03-03 14:07 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-03 14:07 [RFC][GSoC 2026] Proposal: Improve the new git repo command Pushkar Singh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox