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`. - Create a new command to query repository-level information, potentially making it machine-readable via for example JSON. This would move such information out of git-rev-parse(1), which is a somewhat weird home for it. It's something I have been thinking about quite a bit, but it wasn't ever discussed to the best of my knowledge. So maybe not a good fit. I'll keep on thinking about potential topics. Patrick
