{"thread":{"id":"65373","subject":"[GSoC][RFC] Proposal draft for \"Improve the new git repo command\"","startedAt":"2026-03-28T12:53:02Z","lastAt":"2026-03-28T12:53:02Z","messageCount":1,"participants":["Mahlet Kassa"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"540267","messageId":"CACcFiUZ6jgVua-BK=eR7Sjet99UsDKFxTFVQ6E2GqdT8VyL=qg@mail.gmail.com","threadId":"65373","inReplyTo":null,"subject":"[GSoC][RFC] Proposal draft for \"Improve the new git repo command\"","fromName":"Mahlet Kassa","fromEmail":"mahlet.takassa@gmail.com","sentAt":"2026-03-28T12:52:50Z","receivedAt":"2026-03-28T12:53:02Z","isPatch":false,"body":"Hi,\n\nI am applying to Git for GSoC 2026 and wanted to send my current\nproposal draft for feedback.\n\nThe project I am proposing is Improve the new git repo command.\n\nMy current draft focuses on small improvements to `git repo info` and\n`git repo structure`. Right now I am mainly thinking about selected\npath-related values currently obtained through `git rev-parse`,\nclearer grouping of returned information, and small improvements to\nthe current structure statistics.\n\nI am trying to keep the scope small and reviewable instead of turning\nit into one large feature series.\n\nDuring the application period, I also sent a small patch in the same area:\n\n- `repo: show subcommand-specific help text`\n- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`\n\nI have included my current proposal draft below.\n\nI would especially appreciate feedback on whether the scope looks\nreasonable for a 175-hour project, and whether the proposed `git repo\ninfo` / `git repo structure` direction seems like a sensible way to\napproach this idea.\n\nThanks,\nMahlet Kassa\n\n---\n\n# Git GSoC 2026 Proposal\n\n## Title\n\nImprove the new `git repo` command\n\n## Organization\n\nGit\n\n## Project idea\n\n`Improve the new git repo command`\n\n## Expected project size\n\n175 hours\n\n## Proposal summary\n\nI am applying to Git for GSoC 2026 with the project idea `Improve the\nnew git repo command`.\n\nThe part of this project that interests me most is that it is focused,\nconcrete, and close to the code I have already started reading during\nthe application period. The `git repo` command is still new and, based\non the idea page, there is still room to improve both the information\nit returns and how that information is organized. My current proposal\nis to work on small and reviewable improvements to `git repo info` and\n`git repo structure`, instead of treating the project as a large\nredesign.\n\n## Problem statement\n\nThe Git SoC 2026 ideas page lists several possible directions for this\nproject. These include adding path-related values currently obtained\nthrough `git rev-parse`, returning values by category, and extending\n`git repo structure` with more repository analysis or statistics.\n\nWhat makes this project interesting to me is that these are not\ncompletely separate tasks. They all relate to a broader question of\nwhat `git repo` should expose, how it should present this information,\nand where it should complement existing commands without overlapping\nwith them too much.\n\nFor that reason, I do not want to propose a broad feature expansion\nwith unclear boundaries. I would rather work on a few concrete\nimprovements that are useful, tested, and discussed early on the\nmailing list.\n\n## Why this project fits me\n\nI am currently a software engineering student at 42 Berlin. Prior to\nthat I primarily coded in Python as a cognitive science researcher. At\n42 however, almost all of my projects so far have been in C, Unix\nsystems, shell work, and lower-level programming. I am still early in\nmy coding journey, but this is also why Git is a strong fit for me as\nan organization. It is a tool I already use, and this project would\npush me further in areas I want to improve in: reading and navigating\nlarge C codebases, understanding existing command behavior, and\nlearning how to contribute through a review-based development process.\n\nAt the same time, I do think I already have some useful preparation\nfor this kind of work. My recent projects have made me more\ncomfortable reading C code, debugging command-line behavior, and\nwriting tests around small behavioral changes. That is still a limited\nlevel of experience, but I think it is a good base for a project that\nneeds careful, incremental work.\n\nI also think this specific project is a better fit for me than a\nbroader or more protocol-heavy Git idea, because it gives me a\nconcrete place to start. The idea page already points to\n`builtin/repo.c`, the `git repo` documentation, and comparisons with\n`git rev-parse`, which makes it possible to approach the work in a\nstructured way.\n\n## Background and preparation\n\nDuring the application period, I built Git locally, read through the\nimplementation around `git repo`, and worked on a small patch in this\narea.\n\nThe patch I sent was:\n\n- `repo: show subcommand-specific help text`\n- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`\n\nThis patch touched:\n\n- `builtin/repo.c`\n- `t/t1900-repo-info.sh`\n- `t/t1901-repo-structure.sh`\n\nThis was useful preparation for the current proposal because it\nrequired me to read the command implementation and tests closely,\nunderstand how the subcommands are wired, and go through the\nmailing-list submission process in the same part of the codebase as\nthe proposed project.\n\nThe patch also received positive feedback from Junio C Hamano and was\nqueued. For me, the main value of that contribution is not only that\nit was accepted, but that it helped me understand the workflow I would\nneed to follow for this kind of work.\n\n## Proposed work\n\nMy current plan is to focus on two parts of `git repo`.\n\n### 1. Improve `git repo info`\n\nOne likely direction here is to add selected path-related values that\nusers currently get through `git rev-parse`. Another is to improve how\nreturned values are grouped or presented.\n\nMy current thinking is to start with a small set of path-related\nvalues that seem clearly useful, add those first, test them, and then\nsee what still makes sense to add after discussion.\n\nI do not want to approach this as an attempt to copy `git rev-parse`.\nInstead, I want to look at which values make sense in `git repo info`,\nwhich ones are genuinely useful, and how they can be exposed in a way\nthat is still clear and consistent.\n\n### 2. Improve `git repo structure`\n\nThe second part of the project would focus on extending or improving\nthe statistics reported by `git repo structure`.\n\nHere I would also prefer to start with one small improvement to the\ncurrent statistics and keep it limited enough that it is easy to\nreview and discuss.\n\nHere again, I want to keep the work limited to additions that are\nuseful and easy to justify. I do not think it would be a good idea to\nmake the command noisy or overly broad. The goal would be to make it\nmore informative while keeping the interface focused.\n\n## How I would approach the work\n\nMy plan would be to start from the current implementation and refine\nthe exact scope through discussion with the Git community.\n\nThe steps would be roughly the following:\n\n1. Read more of `builtin/repo.c`, the existing tests, and the current\ndocumentation.\n2. Compare the current behavior of `git repo info` with `git\nrev-parse` to identify useful gaps.\n3. Choose a first small improvement that is easy to discuss and review.\n4. Implement the change together with tests and documentation updates.\n5. Send the patch series to the mailing list and revise it based on feedback.\n6. Continue with the next small improvement only after the previous\nstep is reasonably settled.\n\nI think this kind of step-by-step approach is important for this\nproject because the harder part is not only writing code, but also\ndeciding what should belong in `git repo` in the first place.\n\n## Deliverables\n\nAt the moment, I expect the project to produce:\n\n- one or more improvements to `git repo info`\n- one or more improvements to `git repo structure`\n- tests for new behavior\n- documentation updates where needed\n- mailing-list patch series for each milestone\n\nThe exact patch breakdown should remain flexible until there is more\ndiscussion about the design direction.\n\n## Timeline\n\n### Community bonding period\n\n- read more of the current `git repo` implementation and nearby code\n- review prior discussions related to `git repo`\n- ask for feedback on the project direction\n- narrow the project into a smaller set of changes that seem realistic\nto work on one by one\n\n### First phase\n\n- start with one small `git repo info` change that seems useful and realistic\n- implement it with tests and documentation updates if needed\n- send the first patch series\n- revise it based on feedback\n\n### Second phase\n\n- continue with the next `git repo info` improvement if that still\nseems like the right direction\n- or shift to better grouping/classification if discussion suggests\nthat would be more useful\n- update tests and documentation as needed\n- keep revising based on feedback\n\n### Third phase\n\n- work on one small improvement to `git repo structure`\n- keep the scope limited enough that it is still easy to discuss and review\n- test the output carefully\n- revise it based on feedback\n\n### Final phase\n\n- complete follow-up fixes or smaller improvements that fit the agreed scope\n- strengthen tests where needed\n- address remaining review comments\n\n## Risks and constraints\n\nThe main risk in this project is scope. Since `git repo` is still new,\nthere are many possible directions that sound reasonable at first. I\nthink the best way to deal with this is to keep the project limited to\na few concrete improvements and to discuss them early rather than\ndeciding too much in advance on my own.\n\nAnother risk is that some additions may overlap too much with existing\ncommands. That is why I want comparisons with `git rev-parse` and\nmailing-list discussion to be part of the work from the start, not\nsomething that only happens after implementation.\n\nFinally, review iteration itself takes time. For Git this is normal,\nso I think the practical response is to keep changes small and send\nthem early enough that there is time to revise them properly.\n\n## Communication plan\n\nI plan to communicate mainly through the Git mailing list and to\nfollow the normal Git contribution workflow.\n\nIn practice, that means:\n\n- asking questions early when I am unsure about design direction\n- sending proposal drafts and patch series early enough for feedback\n- keeping changes small and testable\n- revising patches based on review comments\n\n## Why I want to work with Git\n\nWhat attracts me to Git is not only that it is an important project,\nbut also that small behavior and interface details matter here in a\nserious way. I like that commands are expected to be clear,\nconsistent, and carefully reviewed, because that matches the kind of\nwork I want to get better at. Git also feels like a strong fit for me\nbecause it is so closely tied to command-line and Unix-style ways of\nworking, which is where most of my recent learning has been.\n\nI am still early in my software engineering path, and I do not want to\npretend otherwise in this application. At the same time, I think I\nhave already shown through my small `git repo` patch that I can work\nthrough a focused change carefully and follow the review process in\nthis area of the codebase. What I can offer is that I am willing to\nkeep working in that way: read carefully, work incrementally, ask\nquestions when needed, and revise my work based on feedback.\n\n## Prior contribution\n\nMy current Git contribution related to this proposal is:\n\n- `repo: show subcommand-specific help text`\n- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`\n\nIn the final application submission, I plan to include the\nmailing-list thread for this patch and the thread for the proposal\ndraft as supporting material.\n\n## Final note\n\nThis proposal is intentionally specific about the general direction of\nthe work, but still open about the final patch breakdown. I think that\nis the right balance for this project. The details should be refined\nthrough discussion with the Git community and then implemented in\nsmall, reviewable steps.\n"}]}