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

From: Pushkar Singh <[email-masked]>
Date: Tue, 3 Mar 2026 14:07:32 +0000

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: [email-masked]

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/[email-masked]/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/[email-masked]/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/[email-masked]/T/#u
    Related Bug Report: https://lore.kernel.org/git/CAGJzqs=0Zr2iqsTUZdjdwpbtaS7kuBOf=E_XT=[email-masked]/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/[email-masked]/T/#u
    Related Bug Report: https://lore.kernel.org/git/[email-masked]/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/[email-masked]/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/[email-masked]/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/[email-masked]/T/#u
    (2) https://lore.kernel.org/git/CALE2CrQFZngj6_NDuf0S=_-nDrrf6b6r=[email-masked]/
    (3) https://lore.kernel.org/git/[email-masked]/T/#u
    (4) https://lore.kernel.org/git/[email-masked]/T/#u
    (5) https://lore.kernel.org/git/CALE2CrQTvHeu21yLXtRg=[email-masked]/T/#u
    (6) https://lore.kernel.org/git/[email-masked]/T/#u
* Assisted in resolving a git rebase issue on the mailing list
    (1) https://lore.kernel.org/git/CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=[email-masked]/T/#madfc34c4334a7d62baa18b18e3c8fa83600f8455
* Studied the original discussions on git repo
    (1) https://public-inbox.org/git/[email-masked]/t/#u
    (2) https://lore.kernel.org/git/[email-masked]/T/#u
    (3) https://lore.kernel.org/git/[email-masked]/T/#u
    (4) https://lore.kernel.org/git/[email-masked]/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