Re: [proposal][RFC] Improve the new git repo command

> 3. Project Proposal
> 
> 3.1 Why "Improve the new git repo command"?
> This project is particularly compelling because I have closely
> followed its development since its inception. Consistently reading
> the weekly updates (https://lucasoshiro.github.io/gsoc-en/) and
> following the mailing list patches for git repo info has deepened
> my ongoing interest in this specific initiative since GSoC 2025.
> This continuous engagement has provided a strong understanding of
> why the command exists and exactly what needs to be done.

> 3.3 Proposed Solution and Objectives
> The main objective of this project is to implement the changes and
> additions discussed in the introduction to make git repo a complete,
> modern replacement for parts of rev-parse. My proposed solutions are:
> 
> - Removing the global state: The builtin/repo.c file currently opts
>  into using global state by declaring
>  #define USE_THE_REPOSITORY_VARIABLE at the top of the file. My
>  goal is to remove this macro entirely to align with Git's
>  libification efforts. To achieve this, I will refactor functions
>  that implicitly rely on this global state instead of the passed
>  repository context. For example, in get_layout_bare(), the repo
>  argument is currently marked as UNUSED because the function calls
>  is_bare_repository() (which checks global state). I will update
>  this and similar functions to evaluate the explicit repo struct
>  instead.
> 
> - Implementing category keys: I will add a way to map specific
>  categories to a group of values. For example, if a user types
>  git repo info paths, the internal logic will look up the paths
>  category and return git-dir, common-dir, and other related
>  values all at once instead of requiring manual queries for each.
> 
> - Adding path values: I will integrate the missing path values
>  currently obtained through git rev-parse (like toplevel and
>  superproject-working-tree) and --git-path (like index and hooks).
>  Since initial work on this has already started, my goal is to
>  take over the effort, lead the necessary design choices on the
>  mailing list, and complete the implementation.
> 
> - Enhancing repo structure: I will study the external git-sizer
>  tool to figure out which of its repository analysis and
>  statistics features can be natively implemented into the git
>  repo structure sub-command.