From: Karthik Nayak Date: Mon, 16 Mar 2026 18:10:41 GMT Subject: Re: [GSoC][RFC v2] Proposal: Improve the new git repo command Message-ID: In-Reply-To: <20260316130431.1318-1-pushkarkumarsingh1970@gmail.com> Pushkar Singh writes: Hello Pushkar, Thanks for your proposal [snip] > 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. Which existing helpers? > - Clarify semantics(absolute vs relative paths, edge cases) by > discussing on the mailing list before finalizing the behavior. It would be nice if you explained a bit about this, what is the current condition what are your thoughts and what do you plan to implement. > - Add one key (or one closely tied family of keys) per patch. > - Add targeted tests covering: > * bare repositories > * linked worktrees > * submodules > * shallow clones I'd be very interested in what the current test scenario looks like and how we'll improve on top of that. > - Update documentation accordingly. > > I will avoid large changes and focus on small, reviewable patches, > instead of rapidly expanding features. > I agree, most often students underestimate the time needed for iterating and getting reviews on the mailing list. Having smaller well defined patches helps. > > 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. > I'm curios to know about the timeline and how this plans into it. Reading along. > > 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. > I'm not sure what the last sentence here means. > 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. In this cycle? IF we do go with category-based queries, isn't that a design choice which affects all 'git repo info' keys? Would we need to specifically solve for path keys? > - Identify architectural considerations relevant > to builtin/repo.c. > What do you mean by this? > 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. > Something we'd also like to see is if you have other events which might affect the timeline, like exams at college. If not, worthwhile to call it out. > > 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 > ------------ > Ah, seems like you do go over it. > 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. Regards, Karthik