Re: Git project and GSoC 2026

6) Improve `git repo info` so it can show more information than now.

From my side, I have these features in my local backlog:

- remove the dependency on `the_repository`
- use the category as key
- add the path-related values (copied from git-rev-parse "Options for
  Files"):
  - git-dir
  - common-dir
  - toplevel
  - superproject-working-tree
- add more values currently obtained through
`git rev-parse --git-path`:
  - grafts file
  - index file
  - objects directory
  - hooks directory
  - git-prefix
  - other paths that are adjusted by update_common_dir()

I already started to add those path-related values [1], but I think
that the major problem is deciding whether we should use relative or
absolute paths.

I also think that we have room for other information that we retrieve
through commands other than git-rev-parse.

7) Improve `git repo structure` so it can show more stats than now.

I don't know Justin's future plans for this command, but the idea
was to bring some functionality from git-sizer [2] to Git.

I would be willing to mentor any of them, but I don't have much
knowledge on `git repo`, so I think it makes more sense for me to
avoid 6) and 7).

If you want, I can share with you some information about
git-repo-info.

I really appreciate initiatives like git-repo-structure and
git-history that bring features from other tools that make Git
easier to use. This week, I was talked independently with two
friends about how git-blame can be misleading sometimes since it
only shows the last change in a line. One of them really likes
`git log -S` for "blaming" strings and thinks that it's a too
powerful feature that is hidden inside git-log. The other one
showed me Cregit [3], a tool for blaming based on tokens
instead of lines. A "string blame" or a "token blame" could be
a nice GSoC project (but maybe for future editions).


[1] https://github.com/lucasoshiro/git/compare/master...repo-info-path/
[2] https://github.com/github/git-sizer
[3] https://github.com/cregit/cregit