[GSoC][RFC] Proposal draft for "Improve the new git repo command"

[Mahlet Kassa <mahlet.takassa@gmail.com>]

Hi,

I am applying to Git for GSoC 2026 and wanted to send my current
proposal draft for feedback.

The project I am proposing is Improve the new git repo command.

My current draft focuses on small improvements to `git repo info` and
`git repo structure`. Right now I am mainly thinking about selected
path-related values currently obtained through `git rev-parse`,
clearer grouping of returned information, and small improvements to
the current structure statistics.

I am trying to keep the scope small and reviewable instead of turning
it into one large feature series.

During the application period, I also sent a small patch in the same area:

- `repo: show subcommand-specific help text`
- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`

I have included my current proposal draft below.

I would especially appreciate feedback on whether the scope looks
reasonable for a 175-hour project, and whether the proposed `git repo
info` / `git repo structure` direction seems like a sensible way to
approach this idea.

Thanks,
Mahlet Kassa

---

# Git GSoC 2026 Proposal

## Title

Improve the new `git repo` command

## Organization

Git

## Project idea

`Improve the new git repo command`

## Expected project size

175 hours

## Proposal summary

I am applying to Git for GSoC 2026 with the project idea `Improve the
new git repo command`.

The part of this project that interests me most is that it is focused,
concrete, and close to the code I have already started reading during
the application period. The `git repo` command is still new and, based
on the idea page, there is still room to improve both the information
it returns and how that information is organized. My current proposal
is to work on small and reviewable improvements to `git repo info` and
`git repo structure`, instead of treating the project as a large
redesign.

## Problem statement

The Git SoC 2026 ideas page lists several possible directions for this
project. These include adding path-related values currently obtained
through `git rev-parse`, returning values by category, and extending
`git repo structure` with more repository analysis or statistics.

What makes this project interesting to me is that these are not
completely separate tasks. They all relate to a broader question of
what `git repo` should expose, how it should present this information,
and where it should complement existing commands without overlapping
with them too much.

For that reason, I do not want to propose a broad feature expansion
with unclear boundaries. I would rather work on a few concrete
improvements that are useful, tested, and discussed early on the
mailing list.

## Why this project fits me

I am currently a software engineering student at 42 Berlin. Prior to
that I primarily coded in Python as a cognitive science researcher. At
42 however, almost all of my projects so far have been in C, Unix
systems, shell work, and lower-level programming. I am still early in
my coding journey, but this is also why Git is a strong fit for me as
an organization. It is a tool I already use, and this project would
push me further in areas I want to improve in: reading and navigating
large C codebases, understanding existing command behavior, and
learning how to contribute through a review-based development process.

At the same time, I do think I already have some useful preparation
for this kind of work. My recent projects have made me more
comfortable reading C code, debugging command-line behavior, and
writing tests around small behavioral changes. That is still a limited
level of experience, but I think it is a good base for a project that
needs careful, incremental work.

I also think this specific project is a better fit for me than a
broader or more protocol-heavy Git idea, because it gives me a
concrete place to start. The idea page already points to
`builtin/repo.c`, the `git repo` documentation, and comparisons with
`git rev-parse`, which makes it possible to approach the work in a
structured way.

## Background and preparation

During the application period, I built Git locally, read through the
implementation around `git repo`, and worked on a small patch in this
area.

The patch I sent was:

- `repo: show subcommand-specific help text`
- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`

This patch touched:

- `builtin/repo.c`
- `t/t1900-repo-info.sh`
- `t/t1901-repo-structure.sh`

This was useful preparation for the current proposal because it
required me to read the command implementation and tests closely,
understand how the subcommands are wired, and go through the
mailing-list submission process in the same part of the codebase as
the proposed project.

The patch also received positive feedback from Junio C Hamano and was
queued. For me, the main value of that contribution is not only that
it was accepted, but that it helped me understand the workflow I would
need to follow for this kind of work.

## Proposed work

My current plan is to focus on two parts of `git repo`.

### 1. Improve `git repo info`

One likely direction here is to add selected path-related values that
users currently get through `git rev-parse`. Another is to improve how
returned values are grouped or presented.

My current thinking is to start with a small set of path-related
values that seem clearly useful, add those first, test them, and then
see what still makes sense to add after discussion.

I do not want to approach this as an attempt to copy `git rev-parse`.
Instead, I want to look at which values make sense in `git repo info`,
which ones are genuinely useful, and how they can be exposed in a way
that is still clear and consistent.

### 2. Improve `git repo structure`

The second part of the project would focus on extending or improving
the statistics reported by `git repo structure`.

Here I would also prefer to start with one small improvement to the
current statistics and keep it limited enough that it is easy to
review and discuss.

Here again, I want to keep the work limited to additions that are
useful and easy to justify. I do not think it would be a good idea to
make the command noisy or overly broad. The goal would be to make it
more informative while keeping the interface focused.

## How I would approach the work

My plan would be to start from the current implementation and refine
the exact scope through discussion with the Git community.

The steps would be roughly the following:

1. Read more of `builtin/repo.c`, the existing tests, and the current
documentation.
2. Compare the current behavior of `git repo info` with `git
rev-parse` to identify useful gaps.
3. Choose a first small improvement that is easy to discuss and review.
4. Implement the change together with tests and documentation updates.
5. Send the patch series to the mailing list and revise it based on feedback.
6. Continue with the next small improvement only after the previous
step is reasonably settled.

I think this kind of step-by-step approach is important for this
project because the harder part is not only writing code, but also
deciding what should belong in `git repo` in the first place.

## Deliverables

At the moment, I expect the project to produce:

- one or more improvements to `git repo info`
- one or more improvements to `git repo structure`
- tests for new behavior
- documentation updates where needed
- mailing-list patch series for each milestone

The exact patch breakdown should remain flexible until there is more
discussion about the design direction.

## Timeline

### Community bonding period

- read more of the current `git repo` implementation and nearby code
- review prior discussions related to `git repo`
- ask for feedback on the project direction
- narrow the project into a smaller set of changes that seem realistic
to work on one by one

### First phase

- start with one small `git repo info` change that seems useful and realistic
- implement it with tests and documentation updates if needed
- send the first patch series
- revise it based on feedback

### Second phase

- continue with the next `git repo info` improvement if that still
seems like the right direction
- or shift to better grouping/classification if discussion suggests
that would be more useful
- update tests and documentation as needed
- keep revising based on feedback

### Third phase

- work on one small improvement to `git repo structure`
- keep the scope limited enough that it is still easy to discuss and review
- test the output carefully
- revise it based on feedback

### Final phase

- complete follow-up fixes or smaller improvements that fit the agreed scope
- strengthen tests where needed
- address remaining review comments

## Risks and constraints

The main risk in this project is scope. Since `git repo` is still new,
there are many possible directions that sound reasonable at first. I
think the best way to deal with this is to keep the project limited to
a few concrete improvements and to discuss them early rather than
deciding too much in advance on my own.

Another risk is that some additions may overlap too much with existing
commands. That is why I want comparisons with `git rev-parse` and
mailing-list discussion to be part of the work from the start, not
something that only happens after implementation.

Finally, review iteration itself takes time. For Git this is normal,
so I think the practical response is to keep changes small and send
them early enough that there is time to revise them properly.

## Communication plan

I plan to communicate mainly through the Git mailing list and to
follow the normal Git contribution workflow.

In practice, that means:

- asking questions early when I am unsure about design direction
- sending proposal drafts and patch series early enough for feedback
- keeping changes small and testable
- revising patches based on review comments

## Why I want to work with Git

What attracts me to Git is not only that it is an important project,
but also that small behavior and interface details matter here in a
serious way. I like that commands are expected to be clear,
consistent, and carefully reviewed, because that matches the kind of
work I want to get better at. Git also feels like a strong fit for me
because it is so closely tied to command-line and Unix-style ways of
working, which is where most of my recent learning has been.

I am still early in my software engineering path, and I do not want to
pretend otherwise in this application. At the same time, I think I
have already shown through my small `git repo` patch that I can work
through a focused change carefully and follow the review process in
this area of the codebase. What I can offer is that I am willing to
keep working in that way: read carefully, work incrementally, ask
questions when needed, and revise my work based on feedback.

## Prior contribution

My current Git contribution related to this proposal is:

- `repo: show subcommand-specific help text`
- message-id: `<20260323152937.257406-1-mahlet.takassa@gmail.com>`

In the final application submission, I plan to include the
mailing-list thread for this patch and the thread for the proposal
draft as supporting material.

## Final note

This proposal is intentionally specific about the general direction of
the work, but still open about the final patch breakdown. I think that
is the right balance for this project. The details should be refined
through discussion with the Git community and then implemented in
small, reviewable steps.