Hi Lucas and everyone,

On Thu, Jan 29, 2026 at 9:41 PM Lucas Seiki Oshiro
[off-list ref] wrote:

quoted

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.

Thanks a lot for this. I have used it in the new SoC-2026-Ideas page I
just added:

https://git.github.io/SoC-2026-Ideas/

It contains the 3 following projects:

1) Refactoring in order to reduce Git's global state

2) Improve the new `git repo` command

3) Complete and extend the `remote-object-info` command for `git cat-file`

I have removed myself from the potential mentors of project 2), where
I used material from your email.

Otherwise everyone who said they were interested in (co-)mentoring
should be listed as a potential mentor of each of these projects. Feel
free to send MRs or just email requests and I will remove you.

We can still add more projects (and potential (co-)mentors) or maybe
split project 2) into 2 separate projects (one for `git repo info` and
the other one for `git repo structure`). We can also refine the
projects.

Feel free to send PRs or patches!

quoted

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.

Thanks but I prefer to plan to mentor another project for now.

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).

I think it's too much work and too risky at this point for a SGoC. It
could require a lot of discussions on the mailing list before there is
some consensus on the command and the way it should be implemented.

If there was already some kind of consensus about a new command and
how it should work my opinion could be different, but for this year,
yeah, let's just pass on this one.

Thanks.