threads / discuss / 63265

[GSOC PROPOSAL 2025] Machine-Readable Repository Information Query Tool

Subject: [GSOC PROPOSAL 2025] Machine-Readable Repository Information Query Tool

## tl;dr

3 messages between Apr 7, 2025 and Apr 8, 2025.

replies: 2people: 2as markdown or json

MOUMITA DHAR· Apr 7, 2025, 12:29 UTC · lore

Hello , This is my GSOC proposal The doc version - https://docs.google.com/document/d/1f1npZ7Ye-FOZENkfaR4SR2TrgSXnNlI8hvC2T0hJA_Y/edit?usp=sharing

# Proposal for GSOC 2025
## Project \- Machine-Readable Repository Information Query Tool
## Personal information

Name \- Moumita Dhar Email \- [dhar61595@gmail.com](mailto:dhar61595@gmail.com) Github \- [https://github.com/Mou887](https://github.com/Mou887) LinkedIn \- [https://www.linkedin.com/in/moumita-dhar-234940253/](https://www.linkedin.com/in/moumita-dhar-234940253/)

## About me

I’m a self-taught programmer who began my coding journey in 2022\. I got started by taking [CS50: Introduction to Computer Science](https://cs50.harvard.edu/x/) by Harvard University on edX, which sparked my curiosity about how software really works. Since then, I’ve been learning independently, completing several follow-up CS50 courses like **CS50’s Web Programming**, and **CS50’s Understanding Technology**, to build a strong foundation in computer science and software development.

While I hold a university degree, my academic background is **not in computer science**. However, I have consistently dedicated my time and energy to learning programming concepts, tools, and real-world development workflows on my own. I’m passionate about systems programming, developer tools, and contributing to meaningful open-source projects.

I’m participating in GSoC under the **Open Source Beginner** category. Even though I’m not currently a student, GSoC represents a unique opportunity for me to gain valuable mentorship and experience in large-scale software collaboration, while contributing to a project I deeply care about.

Outside of coursework and learning, I’ve also explored Git’s internals through personal projects and patches, and I’m excited to take this further through GSoC.

## Microproject
Status \- Under discussion
Mail thread \- [https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/](https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/)

Description \- I contributed to Git’s `userdiff` system by enhancing syntax detection for shell scripts. I focused on improving how Git highlights and navigates function definitions and words in Bash scripts during diffs. I have iterated over four patch versions based on reviewer feedback.

## Project Overview: Decluttering `git rev-parse`

The core purpose of the command was to \- **Parse revision identifiers** like `HEAD`, `master~2`, `origin/HEAD`, or tags.

**Convert symbolic references** into full 40-character commit hashes.
**Resolve user input** into unambiguous commit IDs for internal use.

Over time, developers began adding utility options to `git rev-parse` that had **nothing to do with parsing revisions**, such as:

* `--is-bare-repository`
* `--git-dir`
* `--show-toplevel`
* `--is-inside-work-tree`
This project aims to:
1. **Extract non-revision-parsing functionality from `git rev-parse`.**
      2\.    **Create a new structured command** (e.g., `git
repo-info`) dedicated to:
*   Repository paths and environment
*   Status checks
*   Format queries
*  Superproject relationships
* Git environment variables
## Project Timeline
### Community Bonding Period(Before June 2\)
* Finalize the scope and confirm overall design with mentors.
* Settle on command name (e.g., `git-info`, `git-meta`) and structure.
* Review how `git-rev-parse` implements the related options.
* Draft the expected JSON output format for each functionality area.
### Week 1 (June 2–8): Repository Path Information
* .Implement logic to report on repository layout and paths:
   `.git` directory, common directory, top-level path, relative and
absolute paths, etc.
    Related options: `--git-dir`, `--git-common-dir`, `--git-path`,
`--show-toplevel`,       `--show-cdup`, `--show-prefix`,
`--absolute-git-dir`
*     Introduce new command skeleton and first subcommand infrastructure.
* Output structured data (e.g., JSON).
* Write an initial test suite and begin documentation.
### Week 2 (June 9–15): Git Environment Context
*  Handle environment reporting:-
      List Git-relevant environment variables (e.g., `GIT_DIR`,
`GIT_WORK_TREE`, etc.)
      Related option: `--local-env-vars`
*  Ensure the output is shell-safe and informative for scripting use.
* Write tests covering multiple shell environments.
* Finalize docs and polish previous week’s code based on mentor feedback.
### **Week 3 (June 16–22): Repository State and Status**
* Implement checks for current repo state:-
               If the repo is a bare repo, shallow clone,  inside
`.git` or working tree.
   Related options: `--is-bare-repository`, `--is-shallow-repository`,
   `--is-inside-git-dir`, `--is-inside-work-tree`
* Add structured output with booleans for each status.
* Test across various repo types (bare, shallow, normal).
* Document usage and update test coverage.
### Week 4 (June 23–29): Object and Ref Format Reporting
* Report the object format and reference storage format used:-
       SHA-1/SHA-256, loose or reftable, etc.
       Related options: `--show-object-format`, `--show-ref-format.`
*  Ensure fallback behavior works for older Git versions or partial
configurations.
*  Add comprehensive tests and documentation for this area.
### Week 5 (June 30–July 6): Review & Midterm Prep
* Integrate feedback on the previous four areas.
* Finalize documentation and tests.
* Clean up patch series.
* Run full test suite and verify output consistency.
* Prepare for **midterm submission**.
### Week 6 (July 7–13): Superproject Awareness
*  Implement logic to determine whether the current repo is inside a
superproject:-
                Show the outer working tree if present.
                Related option: `--show-superproject-working-tree`
*     Handle edge cases where repo is not a submodule.
*     Write test coverage and update documentation accordingly.
### Week 7 (July 14–20): Path Resolution Logic
* Add functionality to resolve Git-related paths:
                Handle symlinks, relative paths, and `.git` indirection.
                 Related option: `--resolve-git-dir`
* Focus on correctness and compatibility.
* Add comprehensive tests (symlinks, embedded repos, relative vs absolute).
* Document clearly.
### Week 8 (July 21–27): Code Review & Integration
* Submit patch series for areas from Weeks 6–7.
* Begin integrating all subcommands into a consistent command structure.
* Ensure consistent JSON schema and error handling.
* Begin polish and unification.
### Week 9 (July 28–Aug 3): Unified Output and CLI Polish
* Implement a top-level dispatcher for all functionality areas.
* Add `--format=json` or similar flags for consistent CLI interface.
* Write integration tests across all supported repo states.
* Run  full test suite in clean and dirty trees.
### Week 10 (Aug 4–10): Final Documentation and Usability
*  Write a complete manpage for the new command.
* Add real-world examples and shell usage patterns.
* Run `check-docs`, validate formatting and help output.
### Week 11 (Aug 11–17): Final Mentor Review and Bugfixes
* Submit a full final patch series.
* Incorporate the last round of mentor feedback.
* Clean up commit messages and inline comments.
* Final CI runs and Git project best practices review.
###  Week 12 (Aug 18–24): Submission and Wrap-Up
* Submit final work to Git mailing list (if not already).
* Complete final report, blog post, and GSoC submission.
* Add final tests or polish based on review feedback.
### Final Week
* Reserved for unforeseen delays or last-minute polish.
### Time period from April 9 to  May 6

During this period, I plan to work on a **practice patch** based on my current understanding of the project. This will help me evaluate how well I can implement the ideas outlined in my proposal and whether the timeline I’ve suggested is realistic.

This preparatory work will allow me to:
* Explore the relevant parts of the codebase in more depth
* Validate my implementation approach with a small, isolated prototype
* Build confidence in handling Git’s development workflow
(compilation, testing, patch submission, etc.)

I understand that official coding for GSoC begins in June, and I will reserve actual patch submissions for that period, in accordance with GSoC guidelines. The goal of this exercise is solely to prepare myself to contribute effectively and responsibly from day one.

## Blogging

I will maintain a blog to document my progress, challenges, and learnings throughout the program. This will serve both as a personal reflection and a way to give back to the community by helping future contributors understand the development process within Git. I will post regular updates—starting from the community bonding period through to the final evaluation—covering details like subcommand implementation, testing strategies, mailing list interactions, and reviews. My blog :- [https://hashnode.com/@Moumita](https://hashnode.com/@Moumita)

## Post GSOC

My involvement with Git will not end with the GSoC coding period. I intend to continue contributing to the Git project even after GSoC concludes by following up on any remaining feedback related to my project, further refining and expanding the new command as needed, and actively participating in the community through patch reviews and mailing list discussions. I also plan to explore and work on other issues or features in the Git codebase that align with my interests. Through GSoC, I hope to establish myself as a long-term contributor to Git. I see this project not just as a summer commitment, but as the start of a deeper and ongoing engagement with the Git project and the broader open source community.

## Availability

I am fully available for GSoC and can dedicate **approximately 8 hours per day, 7 days a week**, which totals to **about 50–56 hours per week**. I do not have any academic or job commitments during the GSoC period and can devote my full attention to the project.

This flexibility allows me to accommodate feedback, mentor communication, code reviews, and unexpected blockers without falling behind on the proposed timeline. I'm also willing to adjust my schedule if needed to better sync with my mentor’s availability or project needs.

Karthik Nayak· Apr 8, 2025, 13:58 UTC · re: MOUMITA DHAR · lore

Re: [GSOC PROPOSAL 2025] Machine-Readable Repository Information Query Tool

MOUMITA DHAR <dhar61595@gmail.com> writes:
Hello Moumita,
Show 34 quoted lines
> Hello ,
> This is my GSOC proposal
> The doc version -
> https://docs.google.com/document/d/1f1npZ7Ye-FOZENkfaR4SR2TrgSXnNlI8hvC2T0hJA_Y/edit?usp=sharing
>
> # Proposal for GSOC 2025
>
> ## Project \- Machine-Readable Repository Information Query Tool
>
> ## Personal information
>
> Name \- Moumita Dhar
> Email \- [dhar61595@gmail.com](mailto:dhar61595@gmail.com)
> Github \- [https://github.com/Mou887](https://github.com/Mou887)
> LinkedIn \- [https://www.linkedin.com/in/moumita-dhar-234940253/](https://www.linkedin.com/in/moumita-dhar-234940253/)
>
> ## About me
>
> I’m a self-taught programmer who began my coding journey in 2022\. I
> got started by taking [CS50: Introduction to Computer
> Science](https://cs50.harvard.edu/x/) by Harvard University on edX,
> which sparked my curiosity about how software really works. Since
> then, I’ve been learning independently, completing several follow-up
> CS50 courses like **CS50’s Web Programming**, and **CS50’s
> Understanding Technology**, to build a strong foundation in computer
> science and software development.
>
> While I hold a university degree, my academic background is **not in
> computer science**. However, I have consistently dedicated my time and
> energy to learning programming concepts, tools, and real-world
> development workflows on my own. I’m passionate about systems
> programming, developer tools, and contributing to meaningful
> open-source projects.
>

The rules [1] don't mention anything about requiring a *computer science*, so all participants are welcome!

Show 55 quoted lines
> I’m participating in GSoC under the **Open Source Beginner** category.
> Even though I’m not currently a student, GSoC represents a unique
> opportunity for me to gain valuable mentorship and experience in
> large-scale software collaboration, while contributing to a project I
> deeply care about.
>
> Outside of coursework and learning, I’ve also explored Git’s internals
> through personal projects and patches, and I’m excited to take this
> further through GSoC.
>
> ## Microproject
>
> Status \- Under discussion
>
> Mail thread \- [https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/](https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/)
>
> Description \-  I contributed to Git’s `userdiff` system by enhancing
> syntax detection for shell scripts. I focused on improving how Git
> highlights and navigates function definitions and words in Bash
> scripts during diffs. I have iterated over four patch versions based
> on reviewer feedback.
>
> ## Project Overview: Decluttering `git rev-parse`
>
> The core purpose of the command was to \-
> **Parse revision identifiers** like `HEAD`, `master~2`, `origin/HEAD`, or tags.
>
> **Convert symbolic references** into full 40-character commit hashes.
>
> **Resolve user input** into unambiguous commit IDs for internal use.
>
> Over time, developers began adding utility options to `git rev-parse`
> that had **nothing to do with parsing revisions**, such as:
>
> * `--is-bare-repository`
>
> * `--git-dir`
>
> * `--show-toplevel`
>
> * `--is-inside-work-tree`
>
> This project aims to:
>
> 1. **Extract non-revision-parsing functionality from `git rev-parse`.**
>
>       2\.    **Create a new structured command** (e.g., `git
> repo-info`) dedicated to:
>
> *   Repository paths and environment
> *   Status checks
> *   Format queries
> *  Superproject relationships
> * Git environment variables
>

Makes sense, like I mentioned on another proposal [2], it would be nice to mention that everything under 'Options for Files' section of the 'git rev-parse' manpage probably needs a new home.

I also think you should elaborate on how the new command would look like, will we simply copy over the options? Will there be better consistent naming? What would the default output for 'git repo-info' be? Also how do you justify the name? Is it consistent with the command names in Git? Is it self-explanatory?

It would also be nice to write a brief about how you plan to tackle this, not from a timeline perspective but from a technical perspective.

Show 8 quoted lines
> ## Project Timeline
>
> ### Community Bonding Period(Before June 2\)
>
> * Finalize the scope and confirm overall design with mentors.
>
> * Settle on command name (e.g., `git-info`, `git-meta`) and structure.
>

I would suggest involving the mailing list as soon as possible, as you'd get some good feedback around the early design.

Show 15 quoted lines
> * Review how `git-rev-parse` implements the related options.
>
> * Draft the expected JSON output format for each functionality area.
>
> ### Week 1 (June 2–8): Repository Path Information
>
> * .Implement logic to report on repository layout and paths:
>
>    `.git` directory, common directory, top-level path, relative and
> absolute paths, etc.
>
>     Related options: `--git-dir`, `--git-common-dir`, `--git-path`,
> `--show-toplevel`,       `--show-cdup`, `--show-prefix`,
> `--absolute-git-dir`
>
Nice, I like that the project is broken down into smaller modules.
> *     Introduce new command skeleton and first subcommand infrastructure.
>
> * Output structured data (e.g., JSON).
How do you plan to tackle this? Have you taken a look at json-writer.[c,h]?
Show 18 quoted lines
>
> * Write an initial test suite and begin documentation.
>
> ### Week 2 (June 9–15): Git Environment Context
>
> *  Handle environment reporting:-
>
>       List Git-relevant environment variables (e.g., `GIT_DIR`,
> `GIT_WORK_TREE`, etc.)
>
>       Related option: `--local-env-vars`
>
> *  Ensure the output is shell-safe and informative for scripting use.
>
> * Write tests covering multiple shell environments.
>
> * Finalize docs and polish previous week’s code based on mentor feedback.
>

I think this is a good point. Generally things take long, since we need to sync with the mailing list and ensure it is upto a good standard. Then the topic will slowly move from seen -> next -> master.

Show 79 quoted lines
> ### **Week 3 (June 16–22): Repository State and Status**
>
> * Implement checks for current repo state:-
>
>
>                If the repo is a bare repo, shallow clone,  inside
> `.git` or working tree.
>
>    Related options: `--is-bare-repository`, `--is-shallow-repository`,
>    `--is-inside-git-dir`, `--is-inside-work-tree`
>
> * Add structured output with booleans for each status.
>
> * Test across various repo types (bare, shallow, normal).
>
> * Document usage and update test coverage.
>
> ### Week 4 (June 23–29): Object and Ref Format Reporting
>
> * Report the object format and reference storage format used:-
>
>        SHA-1/SHA-256, loose or reftable, etc.
>
>        Related options: `--show-object-format`, `--show-ref-format.`
>
> *  Ensure fallback behavior works for older Git versions or partial
> configurations.
>
> *  Add comprehensive tests and documentation for this area.
>
> ### Week 5 (June 30–July 6): Review & Midterm Prep
>
> * Integrate feedback on the previous four areas.
>
> * Finalize documentation and tests.
>
> * Clean up patch series.
>
> * Run full test suite and verify output consistency.
>
> * Prepare for **midterm submission**.
>
> ### Week 6 (July 7–13): Superproject Awareness
>
> *  Implement logic to determine whether the current repo is inside a
> superproject:-
>
>
>                 Show the outer working tree if present.
>
>                 Related option: `--show-superproject-working-tree`
>
> *     Handle edge cases where repo is not a submodule.
>
> *     Write test coverage and update documentation accordingly.
>
> ### Week 7 (July 14–20): Path Resolution Logic
>
> * Add functionality to resolve Git-related paths:
>
>
>                 Handle symlinks, relative paths, and `.git` indirection.
>
>                  Related option: `--resolve-git-dir`
>
> * Focus on correctness and compatibility.
>
> * Add comprehensive tests (symlinks, embedded repos, relative vs absolute).
>
> * Document clearly.
>
> ### Week 8 (July 21–27): Code Review & Integration
>
>
>
> * Submit patch series for areas from Weeks 6–7.
>
> * Begin integrating all subcommands into a consistent command structure.
>
Could you expand on what you mean here?
> * Ensure consistent JSON schema and error handling.
>
And here.
Show 6 quoted lines
> * Begin polish and unification.
>
> ### Week 9 (July 28–Aug 3): Unified Output and CLI Polish
>
> * Implement a top-level dispatcher for all functionality areas.
>
This too, what is a dispatcher in context to our codebase?
> * Add `--format=json` or similar flags for consistent CLI interface.
>
> * Write integration tests across all supported repo states.
>

Aren't tests covered as part of each batch of work? What extra do these tests add, why aren't they part of the initial tests?

> * Run  full test suite in clean and dirty trees.
>
This should be part of each batch no?
> ### Week 10 (Aug 4–10): Final Documentation and Usability
>
> *  Write a complete manpage for the new command.
>

I would say each patch should hold corresponding documentation, it is not something we want to work on at the end. We don't want a project left midway without _any_ documentation. it'd be better if there is sufficient documentation added for each new block of changes, that way the state of the project is not lacking at any point. So code, tests, documentation should all be part of each block of work you do.

Show 11 quoted lines
> * Add real-world examples and shell usage patterns.
>
> * Run `check-docs`, validate formatting and help output.
>
>
> ### Week 11 (Aug 11–17): Final Mentor Review and Bugfixes
>
> * Submit a full final patch series.
>
> * Incorporate the last round of mentor feedback.
>
I think this too, is part of each step of the process.
Show 16 quoted lines
> * Clean up commit messages and inline comments.
>
> * Final CI runs and Git project best practices review.
>
> ###  Week 12 (Aug 18–24): Submission and Wrap-Up
>
> * Submit final work to Git mailing list (if not already).
>
> * Complete final report, blog post, and GSoC submission.
>
> * Add final tests or polish based on review feedback.
>
> ### Final Week
>
> * Reserved for unforeseen delays or last-minute polish.
>

Overall, it seems like we're building up to the end for a big patch series in the end. The recommended route would be to split the work into small chunks and get each chunk through one at a time. Each chunk would contain necessary code, tests, documentation and should be in a state where it can be merged to the maintree.

Show 59 quoted lines
> ### Time period from April 9 to  May 6
>
> During this period, I plan to work on a **practice patch** based on my
> current understanding of the project. This will help me evaluate how
> well I can implement the ideas outlined in my proposal and whether the
> timeline I’ve suggested is realistic.
>
> This preparatory work will allow me to:
>
> * Explore the relevant parts of the codebase in more depth
>
> * Validate my implementation approach with a small, isolated prototype
>
> * Build confidence in handling Git’s development workflow
> (compilation, testing, patch submission, etc.)
>
> I understand that official coding for GSoC begins in June, and I will
> reserve actual patch submissions for that period, in accordance with
> GSoC guidelines. The goal of this exercise is solely to prepare myself
> to contribute effectively and responsibly from day one.
>
> ## Blogging
>
> I will maintain a blog  to document my progress, challenges, and
> learnings throughout the program. This will serve both as a personal
> reflection and a way to give back to the community by helping future
> contributors understand the development process within Git. I will
> post regular updates—starting from the community bonding period
> through to the final evaluation—covering details like subcommand
> implementation, testing strategies, mailing list interactions, and
> reviews.
> My blog :- [https://hashnode.com/@Moumita](https://hashnode.com/@Moumita)
>
> ## Post GSOC
>
> My involvement with Git will not end with the GSoC coding period. I
> intend to continue contributing to the Git project even after GSoC
> concludes by following up on any remaining feedback related to my
> project, further refining and expanding the new command as needed, and
> actively participating in the community through patch reviews and
> mailing list discussions. I also plan to explore and work on other
> issues or features in the Git codebase that align with my interests.
> Through GSoC, I hope to establish myself as a long-term contributor to
> Git. I see this project not just as a summer commitment, but as the
> start of a deeper and ongoing engagement with the Git project and the
> broader open source community.
>
> ## Availability
>
> I am fully available for GSoC and can dedicate **approximately 8 hours
> per day, 7 days a week**, which totals to **about 50–56 hours per
> week**. I do not have any academic or job commitments during the GSoC
> period and can devote my full attention to the project.
>
> This flexibility allows me to accommodate feedback, mentor
> communication, code reviews, and unexpected blockers without falling
> behind on the proposed timeline. I'm also willing to adjust my
> schedule if needed to better sync with my mentor’s availability or
> project needs.
Thanks for the proposal!
- Karthik

[1]: https://summerofcode.withgoogle.com/rules [2]: https://lore.kernel.org/git/CAOLa=ZQSnwSPw1U_-2YZzjK5z_jUEB3vGy=So5e+gpOa87Ei=w@mail.gmail.com/T/#mc4c5c87594cd2e0ea795259a6868b3494781cf86

MOUMITA DHAR· Apr 8, 2025, 18:35 UTC · re: Karthik Nayak · lore

Re: [GSOC PROPOSAL 2025] Machine-Readable Repository Information Query Tool

On Tue, 8 Apr 2025 at 19:28, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 43 quoted lines
>
> MOUMITA DHAR <dhar61595@gmail.com> writes:
>
> Hello Moumita,
>
> > Hello ,
> > This is my GSOC proposal
> > The doc version -
> > https://docs.google.com/document/d/1f1npZ7Ye-FOZENkfaR4SR2TrgSXnNlI8hvC2T0hJA_Y/edit?usp=sharing
> >
> > # Proposal for GSOC 2025
> >
> > ## Project \- Machine-Readable Repository Information Query Tool
> >
> > ## Personal information
> >
> > Name \- Moumita Dhar
> > Email \- [dhar61595@gmail.com](mailto:dhar61595@gmail.com)
> > Github \- [https://github.com/Mou887](https://github.com/Mou887)
> > LinkedIn \- [https://www.linkedin.com/in/moumita-dhar-234940253/](https://www.linkedin.com/in/moumita-dhar-234940253/)
> >
> > ## About me
> >
> > I’m a self-taught programmer who began my coding journey in 2022\. I
> > got started by taking [CS50: Introduction to Computer
> > Science](https://cs50.harvard.edu/x/) by Harvard University on edX,
> > which sparked my curiosity about how software really works. Since
> > then, I’ve been learning independently, completing several follow-up
> > CS50 courses like **CS50’s Web Programming**, and **CS50’s
> > Understanding Technology**, to build a strong foundation in computer
> > science and software development.
> >
> > While I hold a university degree, my academic background is **not in
> > computer science**. However, I have consistently dedicated my time and
> > energy to learning programming concepts, tools, and real-world
> > development workflows on my own. I’m passionate about systems
> > programming, developer tools, and contributing to meaningful
> > open-source projects.
> >
>
> The rules [1] don't mention anything about requiring a *computer
> science*, so all participants are welcome!
>

Thank you! As someone coming from a non-traditional CS background, that’s really reassuring. I’m looking forward to contributing and learning as much as I can during the program!

Show 59 quoted lines
> > I’m participating in GSoC under the **Open Source Beginner** category.
> > Even though I’m not currently a student, GSoC represents a unique
> > opportunity for me to gain valuable mentorship and experience in
> > large-scale software collaboration, while contributing to a project I
> > deeply care about.
> >
> > Outside of coursework and learning, I’ve also explored Git’s internals
> > through personal projects and patches, and I’m excited to take this
> > further through GSoC.
> >
> > ## Microproject
> >
> > Status \- Under discussion
> >
> > Mail thread \- [https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/](https://lore.kernel.org/git/20250330134018.9662-2-dhar61595@gmail.com/)
> >
> > Description \-  I contributed to Git’s `userdiff` system by enhancing
> > syntax detection for shell scripts. I focused on improving how Git
> > highlights and navigates function definitions and words in Bash
> > scripts during diffs. I have iterated over four patch versions based
> > on reviewer feedback.
> >
> > ## Project Overview: Decluttering `git rev-parse`
> >
> > The core purpose of the command was to \-
> > **Parse revision identifiers** like `HEAD`, `master~2`, `origin/HEAD`, or tags.
> >
> > **Convert symbolic references** into full 40-character commit hashes.
> >
> > **Resolve user input** into unambiguous commit IDs for internal use.
> >
> > Over time, developers began adding utility options to `git rev-parse`
> > that had **nothing to do with parsing revisions**, such as:
> >
> > * `--is-bare-repository`
> >
> > * `--git-dir`
> >
> > * `--show-toplevel`
> >
> > * `--is-inside-work-tree`
> >
> > This project aims to:
> >
> > 1. **Extract non-revision-parsing functionality from `git rev-parse`.**
> >
> >       2\.    **Create a new structured command** (e.g., `git
> > repo-info`) dedicated to:
> >
> > *   Repository paths and environment
> > *   Status checks
> > *   Format queries
> > *  Superproject relationships
> > * Git environment variables
> >
>
> Makes sense, like I mentioned on another proposal [2], it would be nice
> to mention that everything under 'Options for Files' section of the 'git
> rev-parse' manpage probably needs a new home.
> Yes , I understand I will do that.
Show 5 quoted lines
> I also think you should elaborate on how the new command would look
> like, will we simply copy over the options? Will there be better
> consistent naming? What would the default output for 'git repo-info' be?
> Also how do you justify the name? Is it consistent with the command
> names in Git? Is it self-explanatory?
> Yes  I will elaborate on those details in my proposal .I'm currently proposing git repo-info, The name repo-info is self-explanatory and clearly indicates that the command is focused on querying structured metadata and configuration details of a Git repository.I suppose the default output should be plain strings NUL terminated like other plumbing commands .
> It would also be nice to write a brief about how you plan to tackle
> this, not from a timeline perspective but from a technical perspective.
>Sure , I will a technical details section in my proposal
Show 12 quoted lines
> > ## Project Timeline
> >
> > ### Community Bonding Period(Before June 2\)
> >
> > * Finalize the scope and confirm overall design with mentors.
> >
> > * Settle on command name (e.g., `git-info`, `git-meta`) and structure.
> >
>
> I would suggest involving the mailing list as soon as possible, as you'd
> get some good feedback around the early design.
>

Thank you — that’s a great point. I absolutely plan to involve the mailing list early in the process. During the Community Bonding Period, I’ll draft an initial design proposal outlining the command name, subcommand structure, and output format conventions (especially for JSON output), and share it on the mailing list for feedback.

Show 24 quoted lines
> > * Review how `git-rev-parse` implements the related options.
> >
> > * Draft the expected JSON output format for each functionality area.
> >
> > ### Week 1 (June 2–8): Repository Path Information
> >
> > * .Implement logic to report on repository layout and paths:
> >
> >    `.git` directory, common directory, top-level path, relative and
> > absolute paths, etc.
> >
> >     Related options: `--git-dir`, `--git-common-dir`, `--git-path`,
> > `--show-toplevel`,       `--show-cdup`, `--show-prefix`,
> > `--absolute-git-dir`
> >
>
> Nice, I like that the project is broken down into smaller modules.
>
> > *     Introduce new command skeleton and first subcommand infrastructure.
> >
> > * Output structured data (e.g., JSON).
>
> How do you plan to tackle this? Have you taken a look at json-writer.[c,h]?
>

Yes, I’ve taken a look at json-writer.[c,h] and plan to use Git’s built-in struct json_writer API to produce structured JSON output. This utility provides a convenient and standardized way to emit JSON data across various commands in Git (e.g., git ls-remote --format=json and git for-each-ref --format=json use this approach).

Show 105 quoted lines
> >
> > * Write an initial test suite and begin documentation.
> >
> > ### Week 2 (June 9–15): Git Environment Context
> >
> > *  Handle environment reporting:-
> >
> >       List Git-relevant environment variables (e.g., `GIT_DIR`,
> > `GIT_WORK_TREE`, etc.)
> >
> >       Related option: `--local-env-vars`
> >
> > *  Ensure the output is shell-safe and informative for scripting use.
> >
> > * Write tests covering multiple shell environments.
> >
> > * Finalize docs and polish previous week’s code based on mentor feedback.
> >
>
> I think this is a good point. Generally things take long, since we need
> to sync with the mailing list and ensure it is upto a good standard.
> Then the topic will slowly move from seen -> next -> master.
>
> > ### **Week 3 (June 16–22): Repository State and Status**
> >
> > * Implement checks for current repo state:-
> >
> >
> >                If the repo is a bare repo, shallow clone,  inside
> > `.git` or working tree.
> >
> >    Related options: `--is-bare-repository`, `--is-shallow-repository`,
> >    `--is-inside-git-dir`, `--is-inside-work-tree`
> >
> > * Add structured output with booleans for each status.
> >
> > * Test across various repo types (bare, shallow, normal).
> >
> > * Document usage and update test coverage.
> >
> > ### Week 4 (June 23–29): Object and Ref Format Reporting
> >
> > * Report the object format and reference storage format used:-
> >
> >        SHA-1/SHA-256, loose or reftable, etc.
> >
> >        Related options: `--show-object-format`, `--show-ref-format.`
> >
> > *  Ensure fallback behavior works for older Git versions or partial
> > configurations.
> >
> > *  Add comprehensive tests and documentation for this area.
> >
> > ### Week 5 (June 30–July 6): Review & Midterm Prep
> >
> > * Integrate feedback on the previous four areas.
> >
> > * Finalize documentation and tests.
> >
> > * Clean up patch series.
> >
> > * Run full test suite and verify output consistency.
> >
> > * Prepare for **midterm submission**.
> >
> > ### Week 6 (July 7–13): Superproject Awareness
> >
> > *  Implement logic to determine whether the current repo is inside a
> > superproject:-
> >
> >
> >                 Show the outer working tree if present.
> >
> >                 Related option: `--show-superproject-working-tree`
> >
> > *     Handle edge cases where repo is not a submodule.
> >
> > *     Write test coverage and update documentation accordingly.
> >
> > ### Week 7 (July 14–20): Path Resolution Logic
> >
> > * Add functionality to resolve Git-related paths:
> >
> >
> >                 Handle symlinks, relative paths, and `.git` indirection.
> >
> >                  Related option: `--resolve-git-dir`
> >
> > * Focus on correctness and compatibility.
> >
> > * Add comprehensive tests (symlinks, embedded repos, relative vs absolute).
> >
> > * Document clearly.
> >
> > ### Week 8 (July 21–27): Code Review & Integration
> >
> >
> >
> > * Submit patch series for areas from Weeks 6–7.
> >
> > * Begin integrating all subcommands into a consistent command structure.
> >
>
> Could you expand on what you mean here?
>

As more subcommands are developed, I will begin consolidating shared functionality—such as repository initialization, option parsing, and JSON output helpers—into a unified structure. This will ensure that repo-info behaves like a well-integrated built-in command, with a consistent CLI interface, code style, and behavior across all its subcommands.

> > * Ensure consistent JSON schema and error handling.
> >
>
> And here.

To support machine-readable output, I will define a consistent JSON schema for each subcommand’s output early in the project. As I implement new features, I’ll ensure they adhere to this schema. Errors will also be reported in a structured way when JSON mode is enabled, using a format like {"error": "descriptive message"}. I will also use Git’s standard mechanisms (die(), error(), return codes) for handling and reporting errors in non-JSON mode.By JSON mode I mean the default output will in plain text and the JSON output wll be with the flag like --format-json.

Show 9 quoted lines
>
> > * Begin polish and unification.
> >
> > ### Week 9 (July 28–Aug 3): Unified Output and CLI Polish
> >
> > * Implement a top-level dispatcher for all functionality areas.
> >
>
> This too, what is a dispatcher in context to our codebase?
> I  meant I’ll implement a subcommand dispatcher similar to how other built-ins do (like builtin/remote.c, which has subcommand dispatching logic). This helps organize the code cleanly and allows users to call git repo-info path, git repo-info env, etc.
Show 8 quoted lines
> > * Add `--format=json` or similar flags for consistent CLI interface.
> >
> > * Write integration tests across all supported repo states.
> >
>
> Aren't tests covered as part of each batch of work? What extra do these
> tests add, why aren't they part of the initial tests?
>

You're right — unit and functional tests should be written during each feature’s development (as part of the patch series). What I meant here was that Week 9 will focus on cross-subcommand integration tests — to ensure they all work together consistently in various repository states

> > * Run  full test suite in clean and dirty trees.
> >
>
> This should be part of each batch no?

Yes , This should me a part of each patch series, I will not include this as a separate point in the proposal

Show 13 quoted lines
>
> > ### Week 10 (Aug 4–10): Final Documentation and Usability
> >
> > *  Write a complete manpage for the new command.
> >
>
> I would say each patch should hold corresponding documentation, it is
> not something we want to work on at the end. We don't want a project
> left midway without _any_ documentation. it'd be better if there is
> sufficient documentation added for each new block of changes, that way
> the state of the project is not lacking at any point. So code, tests,
> documentation should all be part of each block of work you do.
>

Yes I understand it will be a part of each patch series , I will mentiion clearly about this in the proposal.

Show 13 quoted lines
> > * Add real-world examples and shell usage patterns.
> >
> > * Run `check-docs`, validate formatting and help output.
> >
> >
> > ### Week 11 (Aug 11–17): Final Mentor Review and Bugfixes
> >
> > * Submit a full final patch series.
> >
> > * Incorporate the last round of mentor feedback.
> >
>
> I think this too, is part of each step of the process.
 Yes , I have included many unnecessary points in the proposal I will
rectify this.
Show 23 quoted lines
>
> > * Clean up commit messages and inline comments.
> >
> > * Final CI runs and Git project best practices review.
> >
> > ###  Week 12 (Aug 18–24): Submission and Wrap-Up
> >
> > * Submit final work to Git mailing list (if not already).
> >
> > * Complete final report, blog post, and GSoC submission.
> >
> > * Add final tests or polish based on review feedback.
> >
> > ### Final Week
> >
> > * Reserved for unforeseen delays or last-minute polish.
> >
>
> Overall, it seems like we're building up to the end for a big patch
> series in the end. The recommended route would be to split the work into
> small chunks and get each chunk through one at a time. Each chunk would
> contain necessary code, tests, documentation and should be in a state
> where it can be merged to the maintree.
>Yes , I understand and I will mention this clearly in the proposal.
Show 67 quoted lines
> > ### Time period from April 9 to  May 6
> >
> > During this period, I plan to work on a **practice patch** based on my
> > current understanding of the project. This will help me evaluate how
> > well I can implement the ideas outlined in my proposal and whether the
> > timeline I’ve suggested is realistic.
> >
> > This preparatory work will allow me to:
> >
> > * Explore the relevant parts of the codebase in more depth
> >
> > * Validate my implementation approach with a small, isolated prototype
> >
> > * Build confidence in handling Git’s development workflow
> > (compilation, testing, patch submission, etc.)
> >
> > I understand that official coding for GSoC begins in June, and I will
> > reserve actual patch submissions for that period, in accordance with
> > GSoC guidelines. The goal of this exercise is solely to prepare myself
> > to contribute effectively and responsibly from day one.
> >
> > ## Blogging
> >
> > I will maintain a blog  to document my progress, challenges, and
> > learnings throughout the program. This will serve both as a personal
> > reflection and a way to give back to the community by helping future
> > contributors understand the development process within Git. I will
> > post regular updates—starting from the community bonding period
> > through to the final evaluation—covering details like subcommand
> > implementation, testing strategies, mailing list interactions, and
> > reviews.
> > My blog :- [https://hashnode.com/@Moumita](https://hashnode.com/@Moumita)
> >
> > ## Post GSOC
> >
> > My involvement with Git will not end with the GSoC coding period. I
> > intend to continue contributing to the Git project even after GSoC
> > concludes by following up on any remaining feedback related to my
> > project, further refining and expanding the new command as needed, and
> > actively participating in the community through patch reviews and
> > mailing list discussions. I also plan to explore and work on other
> > issues or features in the Git codebase that align with my interests.
> > Through GSoC, I hope to establish myself as a long-term contributor to
> > Git. I see this project not just as a summer commitment, but as the
> > start of a deeper and ongoing engagement with the Git project and the
> > broader open source community.
> >
> > ## Availability
> >
> > I am fully available for GSoC and can dedicate **approximately 8 hours
> > per day, 7 days a week**, which totals to **about 50–56 hours per
> > week**. I do not have any academic or job commitments during the GSoC
> > period and can devote my full attention to the project.
> >
> > This flexibility allows me to accommodate feedback, mentor
> > communication, code reviews, and unexpected blockers without falling
> > behind on the proposed timeline. I'm also willing to adjust my
> > schedule if needed to better sync with my mentor’s availability or
> > project needs.
>
> Thanks for the proposal!
>
> - Karthik
> Thank you for the feedback! I will make sure I clarify the things that I wrote vaguely in this proposal
>
> [1]: https://summerofcode.withgoogle.com/rules
> [2]: https://lore.kernel.org/git/CAOLa=ZQSnwSPw1U_-2YZzjK5z_jUEB3vGy=So5e+gpOa87Ei=w@mail.gmail.com/T/#mc4c5c87594cd2e0ea795259a6868b3494781cf86

← back to recent threads