From: Jialong Wang <jerrywang183@yahoo•com>
To: git@vger•kernel.org
Cc: Jialong Wang <jerrywang183@yahoo•com>
Subject: [GSoC] Proposal draft: Improve the new git repo command
Date: Mon, 16 Mar 2026 07:47:13 -0400 [thread overview]
Message-ID: <9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183@yahoo.com> (raw)
In-Reply-To: 9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183.ref@yahoo.com
Hi,
I plan to apply to Git for GSoC 2026, and I would like to share a draft
proposal for feedback.
The project I am currently most interested in is improving the new
`git repo` command, with a primary focus on extending `git repo info`
with path-related repository metadata.
My draft is below. I would appreciate feedback on whether this scope
looks reasonable, and which parts of the current `git repo` work would
make the best starting point.
Thanks,
Jialong
---
# Improve `git repo info` by adding repository path metadata
## Name
Jialong Wang
## Email
jerrywang183@yahoo•com
## Preferred project size
175 hours
## About me
My name is Jialong Wang, and I plan to apply to Git for GSoC 2026.
I have been getting familiar with Git’s development workflow by building
Git from source, reading the contribution documents, and working on a
microproject. As part of that process, I prepared and sent a patch to
the Git mailing list.
I am interested in the new `git repo` command because it is user-facing,
but also closely tied to Git’s internal repository model. That makes it
a good fit for the kind of work I want to do: understanding existing
code, discussing design details on the mailing list, and implementing
improvements in small, reviewable patches.
Relevant links:
- Microproject discussion thread:
https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/
- Microproject patch thread:
https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/
- SoC 2026 idea page:
https://git.github.io/SoC-2026-Ideas/
## Project summary
I would like to work on improving the new `git repo` command, with a
primary focus on `git repo info`.
The `git repo` command was introduced to provide a cleaner interface for
querying repository metadata. However, several useful path-related
values are still mainly accessed through `git rev-parse` and
`git rev-parse --git-path`. My proposal is to extend `git repo info`
so that it can expose a selected set of those values in a more
structured form.
The goal is not to replace `git rev-parse`, but to make `git repo info`
more useful as a structured interface for repository path metadata.
## Motivation
Today, scripts and tools still often rely on commands such as:
git rev-parse --git-dir
git rev-parse --show-toplevel
git rev-parse --git-path <path>
These commands are useful, but they were not primarily designed as a
structured repository metadata interface.
Since `git repo info` already exists for this purpose, extending it with
path-related values would make repository layout information easier to
query in a cleaner and more consistent way.
I think this is a good GSoC project because it has clear user value, can
be implemented incrementally, and naturally fits Git’s patch-and-review
workflow.
## Current context
I am aware that work on path-related `git repo info` fields has already
started. There have already been patch series for path keys, category
requests, and path formatting. Because of that, I do not want to assume
that the work described on the ideas page is still untouched.
One of my first goals during the bonding period would be to review the
current state of these discussions carefully, identify what remains
open, and refine the project scope based on maintainer feedback. I would
rather build on the current direction than duplicate work that is
already in progress.
I also think this project should be scoped carefully. The ideas page
mentions improvements to both `git repo info` and `git repo structure`,
but for a GSoC project I believe it is more realistic to focus first on
`git repo info` and only expand beyond that if the main work is in good
shape.
## Proposed work
The main objective of this project is to extend `git repo info` with
selected repository path values that are currently obtained through
`git rev-parse` and `git rev-parse --git-path`.
The work will involve:
1. Studying the current implementation of `git repo info`.
2. Comparing its current output with commonly used `git rev-parse`
path queries.
3. Identifying a first small set of missing path-related values to add.
4. Discussing output design on the mailing list, especially where there
are open questions about relative versus absolute paths.
5. Implementing the agreed functionality through small patch series.
6. Adding tests covering the new behavior.
7. Updating documentation if needed.
## Initial scope
The first stage of the project would focus on a small set of commonly
used repository path values, for example:
- `git-dir`
- `common-dir`
- `toplevel`
- `superproject-working-tree`
I think these are a good first target because they are already familiar
to users through `git rev-parse`, and they provide immediate practical
value without requiring a large interface expansion.
Depending on project progress and mailing list feedback, I would then
like to extend support to selected values currently accessed through
`git rev-parse --git-path`, such as:
- index file
- objects directory
- hooks directory
I do not want to promise every possible path-related key up front. I
would rather start with the most straightforward and useful values, get
feedback early, and continue from there.
## My approach to scope and quality
One thing I would like to be careful about is not treating this project
as a simple checklist of fields to add.
I think the quality of the project will depend on three things:
1. choosing a small set of fields that make sense together,
2. agreeing on a consistent path representation,
3. and making sure the result fits naturally into the existing `git repo`
design rather than becoming a thin wrapper over `git rev-parse`.
Because of that, I would prefer to make progress in a few coherent
batches instead of adding many unrelated keys at once.
I also think it is important to keep room for scope reduction. If some
part of the design turns out to be more controversial than expected,
I would prefer to complete a smaller, cleaner set of path fields rather
than stretching the project too broadly.
## Technical approach
The implementation of `git repo` is primarily in `builtin/repo.c`. The
first step would be to understand how `git repo info` currently collects
and prints repository metadata, and how that existing structure can be
extended without making the interface inconsistent.
Many relevant repository paths are already available internally through
helpers such as:
- `repo_get_git_dir()`
- `repo_get_common_dir()`
- `repo_get_work_tree()`
Similarly, `git rev-parse --git-path` already relies on existing path
resolution logic. So the work is not about inventing these values from
scratch, but about exposing a selected subset of them through
`git repo info` in a way that fits its current design.
The first implementation step would be to map existing helpers and path
resolution logic to a small set of `repo info` fields. After that, I
would extend the output code in `builtin/repo.c` to report those fields
in a consistent way.
One of the main design questions is path formatting. The ideas page
explicitly mentions the need to decide between relative and absolute
paths. I do not want to assume the answer in advance. Instead, I would
review the current discussion, compare the behavior of existing
commands, and propose a small, consistent approach on the mailing list.
I also expect that some preparatory cleanup or refactoring may be useful
before adding new fields. If so, I would keep that work minimal and send
it as small separate patches.
## Patch strategy
I expect the implementation to be divided into small patches so that
each change can be reviewed independently.
A likely patch strategy would be:
1. small preparatory cleanup if needed
2. add support for a first path-related key or a very small set of keys
3. extend support with additional related keys
4. add or refine tests for the new behavior
5. update documentation if necessary
If existing in-progress series already cover some of these parts, I
would adjust the breakdown accordingly and focus on what remains useful
and open.
## Tests
Tests would be added to cover the new behavior in common repository
setups.
Depending on the exact scope agreed on, test cases may include:
- ordinary repositories
- linked worktrees
- superproject/submodule cases
- cases where path values differ from simple defaults
I would keep the tests focused on observable behavior instead of
overfitting them to a particular implementation detail.
## What I will not try to do
To keep the project realistic, I do not plan to:
- redesign all of `git repo`
- fully replace `git rev-parse`
- implement every possible repository path query
- work on both `git repo info` and `git repo structure` at full scope in
the same project
The project should stay focused on a well-defined subset of path-related
metadata for `git repo info`.
## Expected deliverables
By the end of the project, I expect to deliver:
- support for a useful set of path-related values in `git repo info`
- tests covering the new functionality
- documentation updates if needed
- one or more patch series discussed and refined on the Git mailing list
## Timeline
### Community bonding period
- Study `builtin/repo.c` and the current `git repo info` implementation
- Review recent and ongoing mailing list discussions related to `git repo`
- Compare current `git repo info` behavior with `git rev-parse`
- Refine the exact scope with mentors and mailing list feedback
### Phase 1
- Implement a first small batch of path-related values
- Send the first patch series
- Address review comments
- Add tests for the first batch
### Phase 2
- Implement additional agreed path values
- Continue design discussion if needed
- Refine implementation and tests based on review feedback
### Phase 3
- Complete remaining agreed work
- Update documentation if necessary
- Rework earlier patches if needed for consistency
- Prepare a final summary of the work
### Buffer time
- Handle review delays
- Fix regressions or edge cases
- Narrow scope if some planned work turns out to be too large
## Risks and mitigation
One risk is that design discussion may take longer than expected,
especially around path representation and output structure.
To reduce that risk, I would keep the patch series small and prioritize
the least controversial values first.
Another risk is overlap with work already in progress. If that happens,
I would adjust the project scope to avoid duplication and focus on what
is still useful and open.
## Why I think I am a good fit
I have already started learning Git’s normal contribution workflow
through a microproject, including building Git from source, running
tests, preparing a patch, and sending it to the mailing list.
This project fits the kind of work I want to do in Git: understanding
existing code, discussing interface details on the mailing list, and
implementing improvements incrementally in small patches.
## References
- SoC 2026 idea page:
https://git.github.io/SoC-2026-Ideas/
- General application information:
https://git.github.io/General-Application-Information/
- `git repo` documentation:
https://git-scm.com/docs/git-repo
- `git rev-parse` documentation:
https://git-scm.com/docs/git-rev-parse
- `git-sizer` project:
https://github.com/github/git-sizer
- Recent patch series adding path-related support to `git repo`:
https://public-inbox.org/git/20260228224252.72788-1-lucasseikioshiro@gmail.com/
- More recent work-in-progress series for category/path keys and
`--path-format`:
https://public-inbox.org/git/pull.2208.v6.git.git.1772428548.gitgitgadget@gmail.com/
- Recent GSoC proposal thread on improving the new `git repo` command:
https://public-inbox.org/git/20260303140732.16886-1-pushkarkumarsingh1970@gmail.com/
- Another recent GSoC proposal thread on improving/extending `git repo`:
https://public-inbox.org/git/CA+rGoLd-1Mb5JG1H1PvE-kyjdznrLVFjwQiMLHtd2ETQ-igmXg@mail.gmail.com/
- Recent proposal thread focused on the same SoC idea:
https://public-inbox.org/git/CAO_P5U3g_+RpnDUmEv_qX-3GVhpxLV97eMxP1apERc0KU_95tQ@mail.gmail.com/
- Recent discussion around `git repo structure` enhancements:
https://public-inbox.org/git/CAO_P5U2f4MD-URre+4ocC=YQ570hr03pZHDk1jvuSOKx4aLOCA@mail.gmail.com/
- Microproject discussion thread:
https://public-inbox.org/git/CAKWWG_nGhD6vqhAS1mkEwBQPrg_YX0+C3-xW=Q3ifFDw4dDviw@mail.gmail.com/
- Microproject patch thread:
https://public-inbox.org/git/20260315231538.68586-1-jerrywang183@yahoo.com/
- Review on the microproject patch thread:
https://public-inbox.org/git/CAOLa=ZTpfHUySnMgCFMnvo2JcRSv8zqFP-cLFSs+Ab5Cy2zsvg@mail.gmail.com/
next parent reply other threads:[~2026-03-16 13:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183.ref@yahoo.com>
2026-03-16 11:47 ` Jialong Wang [this message]
2026-03-16 20:59 ` [GSoC] Proposal draft: Improve the new git repo command Karthik Nayak
2026-03-17 0:28 ` Jialong Wang
2026-03-18 20:08 ` [GSoC proposal v3][RFC] " Jialong Wang
2026-03-16 21:05 ` [GSoC] Proposal draft: " Jialong Wang
[not found] <20260318125303.88730-1-jerrywang183.ref@yahoo.com>
2026-03-18 12:53 ` Jialong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fc1d23fbc7d46349ac01314fbfc06eb.gsoc-proposal-draft-jerrywang183@yahoo.com \
--to=jerrywang183@yahoo$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox