Hi all,

I am Jayesh Daga, a third-year Computer Science undergraduate at VIT Chennai. I would like to submit my proposal for the GSoC 2026 project: "Improve the new git repo command". I would greatly appreciate feedback from the community and mentors.

---

== 1. Personal Information

Name: Jayesh Daga
Email: jayeshdaga99@gmail.com
GitHub: https://github.com/jayesh0104
University: Vellore Institute of Technology, India
Timezone: IST (UTC+5:30)
Availability: 35–40 hours/week (May–August 2026)

---

== 2. About Me

I am a systems-oriented developer with a strong interest in developer tools, version control systems, and backend infrastructure.

I have experience in C, C++, Python, and JavaScript, and have worked on:
- real-time telemetry systems
- CI/CD pipelines
- backend services

I enjoy working close to system internals, where small design decisions can significantly impact usability and performance.

---

== 3. Contributions to Git

I have actively contributed to the Git project, particularly in improving test consistency and aligning with Git’s internal testing framework.

- Replaced raw file checks with `test_path_is_missing` to align with
  Git’s testing conventions
- Fixed incorrect helper usage that could lead to test failures

One of my patches has been integrated into the `next` branch of Git, indicating that it has passed initial review and integration stages.

I have participated in the full upstream contribution workflow:
- Sending patches via git-send-email
- Engaging in mailing list discussions
- Responding to maintainer feedback
- Submitting revised versions (v2, v3)

For example, after feedback from a Git contributor, I identified a mismatch between the commit message and the actual code change and submitted a corrected v3 patch.

Through this process, I gained a strong understanding of:
- Git’s test framework and helper utilities
- The importance of precise commit messages
- Incremental patch-based development and review cycles

---

== 4. Project Overview

The `git repo` command is a recent addition intended to provide a structured interface for querying repository metadata and structure.

However, it currently:
- lacks coverage for many commonly used values
- has limited structure in output
- does not yet serve as a unified abstraction over existing commands

This project aims to evolve `git repo` into a complete, consistent, and script-friendly interface for repository introspection.

---

== 5. Problem Statement

Currently, repository metadata is fragmented across multiple commands:

- `git rev-parse` → paths and repository state
- `git config` → configuration
- external tools like git-sizer → repository metrics

This results in:
- fragmentation (multiple commands required)
- inconsistent output formats
- lack of a unified abstraction

The `git repo` command is intended to address this, but remains incomplete.

---

== 6. Technical Proposal

The implementation will primarily involve extending logic in `builtin/repo.c`, reusing existing helpers used by commands like `rev-parse`, and ensuring consistency with Git’s internal APIs.

### 6.1 Path Metadata Expansion

Add support for:

Core paths:
- paths.git_dir
- paths.common_dir
- paths.toplevel
- paths.superproject_working_tree

Git-path equivalents:
- paths.objects
- paths.index
- paths.hooks
- paths.grafts
- paths.prefix

Design:
- Default to relative paths (portable)
- Optional `--absolute` flag

Final decisions will be made through mailing list discussion.

---

### 6.2 Structured Output

Current output is flat key-value.

Proposed:

{
  "paths": { ... },
  "layout": { ... }
}

Benefits:
- easier machine parsing
- better extensibility
- clearer organization

Backward compatibility will be preserved.

---

### 6.3 Remove Global State

Replace usage of global `the_repository` with explicit:

    struct repository *repo

Benefits:
- improved modularity
- better testability
- future extensibility

---

### 6.4 Extend `git repo structure`

Add metrics inspired by git-sizer:
- object counts
- largest blobs
- tree depth

Ensure:
- incremental additions
- performance safety

---

### 6.5 Testing and Documentation

Testing:
- extend tests in `t/`
- cover edge cases (bare repos, worktrees, submodules)

Documentation:
- update `git-repo.txt`
- include examples and usage patterns

---

== 7. Timeline

Community Bonding:
- study relevant code (`builtin/repo.c`, `repository.c`, `setup.c`)
- initiate mailing list discussions (paths, structure)
- submit small patch

Weeks 1–2:
- implement core path metadata
- testing and review

Weeks 3–4:
- implement git-path equivalents
- ensure parity with rev-parse

Weeks 5–6:
- refactor global state usage
- submit incremental patches

Weeks 7–8:
- structured output implementation
- RFC discussion and iteration

Weeks 9–10:
- extend repo structure metrics
- validate performance

Weeks 11–12:
- polishing, documentation, final review

---

== 8. Risks and Mitigation

Design disagreements:
- addressed via early RFC discussions

Performance concerns:
- benchmark before merging
- optional flags for expensive operations

Review delays:
- mitigated through small, incremental patches

---

== 9. Why Me

I have already contributed to Git and worked through its mailing list development workflow.

Having a patch integrated into the `next` branch and iterating through v2 and v3 revisions has given me practical experience with Git’s expectations around correctness, clarity, and incremental changes.

My background in systems programming allows me to reason about API design, performance trade-offs, and maintainability—key aspects of this project.

---

== 10. Future Work

I intend to continue contributing to Git beyond GSoC, particularly in:
- stabilizing `git repo` as a porcelain command
- improving developer-facing tooling

---

Thank you for your time and consideration. I would greatly appreciate any feedback on this proposal.

Thanks, Jayesh Daga