Re: Git project and GSoC 2026

From: Christian Couder <christian.couder@gmail.com>
Date: Feb 3, 2026, 09:37 UTC
Message-ID: <CAP8UFD0qtn_1VAA1SiAMjGVF7Qv9qC1GdDmsbkK1xvq=SFxTaQ@mail.gmail.com>
In-Reply-To: <21D9FA76-F382-483E-817F-C3947C939D16@gmail.com>

Hi Lucas and everyone,

On Thu, Jan 29, 2026 at 9:41 PM Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> wrote:

Show 29 quoted lines

>
>
> > 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!

Show 6 quoted lines

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

Show 10 quoted lines

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