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

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

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