Re: Git in GSoC 2025

[shejialuo <shejialuo@gmail.com>]

On Mon, Jan 20, 2025 at 08:07:53AM +0100, Patrick Steinhardt wrote:
> On Sun, Jan 19, 2025 at 03:43:29PM +0530, Kaartic Sivaraam wrote:
> > Hello everyone,
> > 
> > It is that time of year. GSoC Org Applications for 2025 are open now[1].
> > They are due before Tuesday, February 11 at 1800 UTC. It's good to see that
> > few contributors have already started working on microprojects this year :-)
> > 
> > I could help as an Org Admin like previous years. I prefer not to
> > volunteer as a mentor this time owing to other commitments, though.
> 
> Thanks for your work, as usual!
> 
> > There are no noticeable changes to the program this year.
> > 
> > The GSoC contributor application period is March 24 - April 8, so
> > (co-)mentors and org admins are already welcome to volunteer. As usual,
> > we also need project ideas to refresh our idea page from last year
> > (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> > thoughts and discuss. It would be great if we could come up with a good mix
> > of small, medium and large projects.
> > 
> > Do feel free to ask if there's anything that needs to be clarified.
> > 
> > Just like previous year, there will be a GSoC Meetup in Brussels during
> > FOSDEM weekend on Saturday, February 1st in the evening. If you are
> > around, interested and haven't received the link to register directly
> > from Google, let me know so I can send it to you.
> > 
> > [1]: https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html
> 
> I'd be happy to mentor this year again. A couple of ideas:
> 
>   - Consolidate ref-related functionality into git-refs(1). This would
>     mean that we add new subcommands "list", "get", "exists", "write"
>     and "optimize" to it so that we have a central place to manage refs
>     overall. This would replace git-update-ref(1), git-for-each-ref(1)
>     git-show-ref(1) as well as git-pack-ref(1), which would of course
>     stay around for the foreseeable future.
> 
>   - Refactor "environment.c" such that more of its global state is
>     instead stored locally, e.g. as part of `struct repository` or
>     `struct repository_settings`.

I think this is a good project which is not too difficult for a student
to finish. By refactoring "environment.c", we could slowly drop the
global variable "the_repository". I'd like to co-mentor with this idea
if possible.

Thanks,
Jialuo