{"thread":{"id":"65291","subject":"Re: [GSoC] Proposal draft: Improve the new git repo command","startedAt":"2026-03-18T12:53:08Z","lastAt":"2026-03-18T12:53:08Z","messageCount":1,"participants":["Jialong Wang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"539286","messageId":"20260318125303.88730-1-jerrywang183@yahoo.com","threadId":"65291","inReplyTo":"20260318125303.88730-1-jerrywang183.ref@yahoo.com","subject":"Re: [GSoC] Proposal draft: Improve the new git repo command","fromName":"Jialong Wang","fromEmail":"jerrywang183@yahoo.com","sentAt":"2026-03-18T12:53:03Z","receivedAt":"2026-03-18T12:53:08Z","isPatch":false,"sender":{"key":"jerrywang183@yahoo.com","avatar":null},"body":"Hi Karthik,\n\nI wanted to send a brief follow-up on my proposal draft for the\n\"Improve the new git repo command\" project.\n\nSince sending the revised draft, I have continued working on small Git\npatches to get more comfortable with the codebase and with the mailing\nlist workflow. In particular, I sent/rerolled:\n\n - an apply.c series on input-location reporting, starting from\n   \"apply: report the location of corrupt patches\" and then extending it\n   to header parsing errors and binary/garbage patch errors, which I\n   rerolled as a single v4 0/3 series after review feedback\n - \"t2203: avoid suppressing git status exit code\"\n - \"object-name: turn INTERPRET_BRANCH_* constants into enum values\"\n\nWorking through these patches helped sharpen how I think about the repo\nproject's scope.\n\nMy current understanding is that the project should probably not try to\nturn \"git repo info\" into a large catch-all for every possible\nrepository path/value right away. Instead, the core scope should be to\ndefine and land a coherent initial set of path-oriented values that are\nalready grounded in existing repository setup / rev-parse style\nplumbing, and to do that as a sequence of small self-contained patches,\neach with its own tests and documentation updates.\n\nFor testing, I now expect the main command-level coverage to live in\nt/t1900-repo-info.sh, while reusing patterns from existing rev-parse and\nrepository setup tests where the semantics overlap.\n\nThis also changed how I think about the timeline: I would prefer to keep\nthe initial milestones focused on a small useful subset with a clear\ninterface, and only treat broader expansion and cleanups as follow-up\nwork once the main direction is in good shape.\n\nIf you have time, I would really appreciate any feedback on whether this\nupdated framing is closer to the direction you had in mind.\n\nThanks,\nJialong\n"}]}