[GSoC][RFC v2] Proposal: Improve the new git repo command

[Pushkar Singh <pushkarkumarsingh1970@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 16372 bytes --]

Hi Everyone,
This is the second version of my proposal for "Improve the new git repo command" in Google Summer of Code 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 Science & 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 v3] path: refactor normalize_path_copy_len for clarity
    Status: Merged into master
    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.

* [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: WIP, 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.

Additional Participation:

In addition to submitting patches, I have:
*  Reviewed patches from other contributors
    (1) https://lore.kernel.org/git/CALE2CrTzYbMam_fi5HszSUFVZADE1haLtpBqhUmd1ki9biM2hA@mail.gmail.com/T/#u
    (2) https://lore.kernel.org/git/20260202134657.15320-1-pushkarkumarsingh1970@gmail.com/T/#u
    (3) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=C9jMyEVjwMqvh6J2w@mail.gmail.com/
    (4) https://lore.kernel.org/git/CALE2CrTuZkFm1R3Bb6gFmrN1trr88vdO_7Aw6ycBYvFpWMEEtA@mail.gmail.com/T/#u
    (5) https://lore.kernel.org/git/CALE2CrSu-JW___Lav0SnLPfwxB8QCRYMKQgsfbXCHrAQSEyDoA@mail.gmail.com/T/#u
    (6) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com/T/#u
    (7) 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 will be iterating on this project in blocks and with the
review-driven approach. By introducing every changes in small,
logically isolated patches, I'll ensure clarity, ease-of-review,
and architectural stability.

First I want to cover foundational repository path keys,
because they create instant structural value and more closely fit
with existing functionalities of rev-parse.

For every key proposed or enhancement made, I will:

  - Ensure behavior matches with existing helpers.
  - Clarify semantics(absolute vs relative paths, edge cases) by
    discussing on the mailing list before finalizing the behavior.
  - Add one key (or one closely tied family of keys) per patch.
  - Add targeted tests covering:
        * bare repositories
        * linked worktrees
        * submodules
        * shallow clones
  - Update documentation accordingly.

I will avoid large changes and focus on small, reviewable patches,
instead of rapidly expanding features.


Path Key Expansion
------------------

I will incrementally expose selected repository path values
currently accessible via:

  - git rev-parse
  - git rev-parse --git-path

My initial focus will be on foundational keys such as:

  path.git-dir
  path.common-dir
  path.toplevel
  path.superproject-working-tree

Subsequent patches may introduce additional --git-path
equivalents such as:

  path.index-file
  path.objects-dir
  path.config-file

Each key will be evaluated individually to ensure clarity,
necessity, and consistent semantics.


Optional: Category-Based Queries (If Aligned)
--------------------------------------------

If agreed upon through mailing list discussion, I will introduce
explicit grouped queries, such as:

  git repo info paths

The expansion will still be deterministic and predefined.
I'll not be introducing any implicit or dynamic grouping behavior.


repo structure Enhancements
---------------------------

If maintainers deem it appropriate maybe I will tackle some 
carefully scoped improvements to git repo structure.

Potential areas include:
  - Distribution-oriented metrics, only if aligned with the
    tool’s long-term direction.
  - Low-friction structural metrics (e.g., path depth),
    as long as they do not add excessive traversal cost.

Any such enhancement will be introduced in small,
standalone patches, taking performance, maintainability, 
and output stability into account. If scope or review
timelines demand, this stage will be delayed.


Architectural Considerations
----------------------------

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 reimplementing path resolution logic.
  - Preserve conservative output stability.

Structural refactoring will only be undertaken when directly
relevant to git repo and supported through review discussion.


Timeline
--------

Keeping Git's iterative and review-driven workflow in mind, I've 
designed the timeline to focus on core enhancements in order to 
ensure that I can produce meaningful deliverables even if review 
cycles extend.


Pre-Coding Preparation (Before Official Start)

- Continue participating in git repo discussions.
- Improve and restrict scope of path key expansion.
- Confirm semantics for absolute vs relative path handling.
- Define patch ordering to keep the 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.

I will get to implementation once the semantics feel 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

  I'll present these foundational keys early on to keep 
  semantics consistent, and stabilize output expectations.

* Week 3:
  - Submit path.toplevel
  - Submit path.superproject-working-tree

  These will provide working-tree inspection coverage to
  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.

I'll submit each key independently. When semantics are 
already aligned, I'll send consecutive patches while
older ones will remain pending, which allows a significant 
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

- Finish the remaining agreed --git-path parity keys.
- Address changes from review cycles of Phase 1.
- Stabilize behaviour across edge-case environments.

This phase purposely leaves time for review-guided
iteration without expanding scope.


Phase 3 (Weeks 9–10): Optional Enhancements

Only if Phase 1 and 2 stabilize earlier than expected,
I'll begin:
- Introducing the grouped category queries(e.g., info paths),
  subject to prior agreement.
- Carefully extending repo structure with one metric 
  at a time.

I’m not going to attempt any bulk metric expansion here.


Final Weeks (Weeks 11–12): Consolidation

Over the last weeks of this program, I will:
- Address remaining review feedback.
- Adjust patches if requested or rework them.
- Finalize documentation.
- Ensure CI stability and cross-platform behavior.

During this time no new features will be introduced.


Prioritization Under Constraints
--------------------------------

Considering Git’s iterative review process, I have structured the
project so that foundational improvements are delivered first.

If review cycles extend longer than anticipated, my 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
4. repo structure metric extensions

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:
---------

For the past one year I have been writing technical articles 
on Medium, mostly related to Git workflows, developer tooling, 
and lessons from working with real codebases.

I will be sharing weekly updates for the GSoC period to document 
progress and the discussions on these mailing lists for 
transparency, and more importantly, to help future contributors.

Medium: https://medium.com/@pushkarscripts


Risk Assessment and Mitigation
------------------------------

1. Review Cycle Duration

Considering Git’s iterative mailing list workflow, existing 
patches might go through several updates before being 
accepted.

Mitigation:
  The project is structured so that foundational path
  keys are delivered first. Independent patches allow
  parallel review and refinement.

2. Scope Creep

Expanding both path keys and structure metrics
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 consideration. I look forward
to contributing further to the project and continuing to
learn through the review process.

Regards, 
Pushkar Singh

---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<

Changes in v2:
- Updated status of my recent patch activities.
- Added recent patch reviews I made in Mailing List.
- Improved clarity and readability across sections.