# Re: [GSoC] Proposal draft: Improve the new git repo command

1 messages from 2026-03-18 to 2026-03-18. Participants: Jialong Wang.
Thread: https://gitlist.dev/t/65291

## Jialong Wang, 2026-03-18 12:53

Subject: Re: [GSoC] Proposal draft: Improve the new git repo command
Message-ID: <20260318125303.88730-1-jerrywang183@yahoo.com>
URL: https://gitlist.dev/e/20260318125303.88730-1-jerrywang183%40yahoo.com
In-Reply-To: <20260318125303.88730-1-jerrywang183.ref@yahoo.com>

```
Hi Karthik,

I wanted to send a brief follow-up on my proposal draft for the
"Improve the new git repo command" project.

Since sending the revised draft, I have continued working on small Git
patches to get more comfortable with the codebase and with the mailing
list workflow. In particular, I sent/rerolled:

 - an apply.c series on input-location reporting, starting from
   "apply: report the location of corrupt patches" and then extending it
   to header parsing errors and binary/garbage patch errors, which I
   rerolled as a single v4 0/3 series after review feedback
 - "t2203: avoid suppressing git status exit code"
 - "object-name: turn INTERPRET_BRANCH_* constants into enum values"

Working through these patches helped sharpen how I think about the repo
project's scope.

My current understanding is that the project should probably not try to
turn "git repo info" into a large catch-all for every possible
repository path/value right away. Instead, the core scope should be to
define and land a coherent initial set of path-oriented values that are
already grounded in existing repository setup / rev-parse style
plumbing, and to do that as a sequence of small self-contained patches,
each with its own tests and documentation updates.

For testing, I now expect the main command-level coverage to live in
t/t1900-repo-info.sh, while reusing patterns from existing rev-parse and
repository setup tests where the semantics overlap.

This also changed how I think about the timeline: I would prefer to keep
the initial milestones focused on a small useful subset with a clear
interface, and only treat broader expansion and cleanups as follow-up
work once the main direction is in good shape.

If you have time, I would really appreciate any feedback on whether this
updated framing is closer to the direction you had in mind.

Thanks,
Jialong

```