Re: Git in GSoC 2025

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 20, 2025, 07:07 UTC
Message-ID: <Z432QXJb_TfzNBa2@pks.im>
In-Reply-To: <8c8e8797-8de9-4684-94a0-f6c17a592dc5@gmail.com>

On Sun, Jan 19, 2025 at 03:43:29PM +0530, Kaartic Sivaraam wrote:

Show 8 quoted lines

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

Show 17 quoted lines

> 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