Git in GSoC 2025

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

> 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

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

> 
> Thank you for suggesting these ideas, Patrick! I've incorporated them 
> into a draft ideas page for now. You can see them here:
> 
> https://git.github.io/SoC-2025-Ideas/
> 
> Kindly suggest any corrections to the description, project size /
> difficulty as necessary. I've mentioned potential mentors based on what
> I'm aware of so far.
> 
> Patrick, Christian and Karthik, kindly mention the ideas that you're
> interested to mentor.
> 

> Hello Christian, Karthik, Jialuo, Patrick and all,
> 
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
> > 
> > Thank you for suggesting these ideas, Patrick! I've incorporated them
> > into a draft ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> > 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary. I've mentioned potential mentors based on what
> > I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to mentor.
> > 
> 
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:

> The following idea mentions Karthik and Patrick as potential
> mentors.
> 
>   - Implement support for reftables in “dumb” HTTP transport
> 
> The following idea mentions Jialuo and Patrick as potential
> mentors.
> 
>   - Consolidate ref-related functionality into git-refs

> Hello Christian, Karthik, Jialuo, Patrick and all,
>
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
>>
>> Thank you for suggesting these ideas, Patrick! I've incorporated them
>> into a draft ideas page for now. You can see them here:
>>
>> https://git.github.io/SoC-2025-Ideas/
>>
>> Kindly suggest any corrections to the description, project size /
>> difficulty as necessary. I've mentioned potential mentors based on what
>> I'm aware of so far.
>>
>> Patrick, Christian and Karthik, kindly mention the ideas that you're
>> interested to mentor.
>>
>
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:
>

> The following idea mentions Karthik and Patrick as potential
> mentors.
>
>    - Implement support for reftables in “dumb” HTTP transport
>

> The following idea mentions Jialuo and Patrick as potential
> mentors.
>
>    - Consolidate ref-related functionality into git-refs
>
> It would helpful if you all could chime in to let me know if the
> existing allocation is fine and to what other projects you need
> to be mentioned as potential mentors.
>
> --
> Sivaraam

> Hello Christian, Karthik, Jialuo, Patrick and all,
> 
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
> > 
> > Thank you for suggesting these ideas, Patrick! I've incorporated them
> > into a draft ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> > 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary. I've mentioned potential mentors based on what
> > I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to mentor.
> > 
> 
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:
> 

>   - Machine-Readable Repository Information Query Tool
> 
> The following idea mentions Karthik and Patrick as potential
> mentors.
> 
>   - Implement support for reftables in “dumb” HTTP transport
> 
> The following idea mentions Jialuo and Patrick as potential
> mentors.
> 
>   - Consolidate ref-related functionality into git-refs
> 

> - Consolidate ref-related functionality into git-refs
>
>    Possible mentors:
>    * Patrick Steinhardt
>    * Jialuo She

> - Refactoring in order to reduce Git's global state
>
>    Possible mentors:
>    * Patrick Steinhardt
>    * Karthik Nayak
>    * Jialuo She

> Note that I haven't assigned any mentors / co-mentors for each project.
> I suppose we could assign that based on the applications we receive and
> the ideas that we end up selecting.
>
> Based on Christian's inputs, we should be able to distribute
> projects among mentors well.

> Hi Kaartic and all,
> 
> On Tue, Feb 4, 2025 at 7:33 PM Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
> 
> I have just added myself as a possible mentor. If possible I'd like to
> just co-mentor this project and someone else to be the main mentor for
> this project.
> 

>> Note that I haven't assigned any mentors / co-mentors for each project.
>> I suppose we could assign that based on the applications we receive and
>> the ideas that we end up selecting.
>>
>> Based on Christian's inputs, we should be able to distribute
>> projects among mentors well.
> 
> Yeah, I hope it will be possible to distribute projects among mentors well.
>

> -- 8< --
>
> Consolidate ref-related functionality into git-refs
>
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
>
> Refactoring in order to reduce Git’s global state
>
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
>
> Machine-Readable Repository Information Query Tool
>
> - Mentor: Karthik
> - Co-mentor: Patrick
>
> Implement support for reftables in “dumb” HTTP transport
>
> - Mentor: Patrick
> - Co-mentor: Karthik
>
> -- >8 --
>
> Let me know if this sounds fine to all of you.

> So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.

> Consolidate ref-related functionality into git-refs
> 
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
> 
> Refactoring in order to reduce Git’s global state
> 
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
> 
> Machine-Readable Repository Information Query Tool
> 
> - Mentor: Karthik
> - Co-mentor: Patrick
> 
> Implement support for reftables in “dumb” HTTP transport
> 
> - Mentor: Patrick
> - Co-mentor: Karthik
> 
> -- >8 --
> 
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.

> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
> 
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.

> One thought: From my point of view I'd strongly favor extending
> git-refs(1) over reftable support in the dumb HTTP transport. So if I
> had two applications, one for each topic, I'd lean towards applications
> for the former topic. That might easily cause unfairness in case
> students aren't aware of that.
> 
> So unless somebody else wants to be main-mentor in that project, I think
> we should either drop the HTTP transport tropic, or communicate our
> priorities clearly.

> Hi Patrick, Christian and all,
>
> On 07/02/25 16:25, Patrick Steinhardt wrote:
> > One thought: From my point of view I'd strongly favor extending
> > git-refs(1) over reftable support in the dumb HTTP transport. So if I
> > had two applications, one for each topic, I'd lean towards applications
> > for the former topic. That might easily cause unfairness in case
> > students aren't aware of that.
> > 
> > So unless somebody else wants to be main-mentor in that project, I think
> > we should either drop the HTTP transport tropic, or communicate our
> > priorities clearly.
>
> That makes sense. I've added a note to convey this clearly. Kindly check 
> if the change in the following PR looks fine.
>
>    https://github.com/git/git.github.io/pull/750/files
>
>
> On 07/02/25 13:37, Christian Couder wrote:
>  > Yeah, but we have time to decide on this. It seems to me that we can
>  > still come up with new project ideas and possibly new mentors or
>  > co-mentors until it's time for applicants to send their.application.
>
> Indeed. More volunteer mentors and ideas are always welcome :-)

> 
> I can co-mentor this summer. The 'Machine-Readable Repository Information
> Query Tool' project seems interesting to me, although I'm up for co-mentoring
> in other projects as well. Let me know if you need any help with
> anything else.
>

> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
>> I can co-mentor this summer. The 'Machine-Readable Repository
>> Information
>> Query Tool' project seems interesting to me, although I'm up for co-mentoring
>> in other projects as well. Let me know if you need any help with
>> anything else.
>>
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.
>
> Also, feel free to share if you have any other ideas that we could have
> for this GSoC.

> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
> > 
> > I can co-mentor this summer. The 'Machine-Readable Repository Information
> > Query Tool' project seems interesting to me, although I'm up for co-mentoring
> > in other projects as well. Let me know if you need any help with
> > anything else.
> >
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.

> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
>>
>> I can co-mentor this summer. The 'Machine-Readable Repository Information
>> Query Tool' project seems interesting to me, although I'm up for co-mentoring
>> in other projects as well. Let me know if you need any help with
>> anything else.
>>
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.
>
> Also, feel free to share if you have any other ideas that we could have
> for this GSoC.
>

> 
> I wonder if with Ghanshyam also mentoring, if this statement still
> holds true
> 
>    Note about limit of project selection
> 
>    Kindly note that considering the bandwidth of available mentors, the
>    Git project would only mentor up to 3 contributors this year.
> 
> Maybe we can do 4 projects this year?
> 

> Hi Karthik,
>
> Sorry for the delayed response! I kind of missed to respond unintentionally.
>
> On 07/03/25 15:31, Karthik Nayak wrote:
>>
>> I wonder if with Ghanshyam also mentoring, if this statement still
>> holds true
>>
>>    Note about limit of project selection
>>
>>    Kindly note that considering the bandwidth of available mentors, the
>>    Git project would only mentor up to 3 contributors this year.
>>
>> Maybe we can do 4 projects this year?
>>
>
> While we do have 5 volunteers for mentoring students this year, we only
> have 3 candidates who could play the role of the primary mentor.
> Ghanshyam and Jialuo only prefer to co-mentor as far as I could
> understand. So, that still gives us a limit of 3 projects doesn't it?
>
> Kindly correct me in case I'm missing anything.
>

> 
> Indeed. From all of your inputs I was able to come to the following
> allocation of mentor / co-mentor.
> 
> -- 8< --
> 
> Consolidate ref-related functionality into git-refs
> 
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
> 
> Refactoring in order to reduce Git’s global state
> 
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
> 
> Machine-Readable Repository Information Query Tool
> 
> - Mentor: Karthik
> - Co-mentor: Patrick
> 
> Implement support for reftables in “dumb” HTTP transport
> 
> - Mentor: Patrick
> - Co-mentor: Karthik
> 
> -- >8 --
> 
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.
> 

> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
> 
> 
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.
> 

> Hi Christian, Karthik, Patrick, Jialuo and all,
>
> On 05/02/25 18:50, Christian Couder wrote:
>> Hi Kaartic and all,
>>
>> On Tue, Feb 4, 2025 at 7:33 PM Kaartic Sivaraam
>> <kaartic.sivaraam@gmail.com> wrote:
>>
>> I have just added myself as a possible mentor. If possible I'd like to
>> just co-mentor this project and someone else to be the main mentor for
>> this project.
>>
>  > ...
>>
>> I have just added myself as a possible mentor. If possible I'd like to
>> be the main mentor for this project.
>>
>
> Thank you for adding yourself as a potential mentor!
>
> With this, it seems to me like we could at the max. accept 3 students
>
>>> Note that I haven't assigned any mentors / co-mentors for each project.
>>> I suppose we could assign that based on the applications we receive and
>>> the ideas that we end up selecting.
>>>
>>> Based on Christian's inputs, we should be able to distribute
>>> projects among mentors well.
>>
>> Yeah, I hope it will be possible to distribute projects among mentors well.
>>
>
> Indeed. From all of your inputs I was able to come to the following
> allocation of mentor / co-mentor.
>
> -- 8< --
>
> Consolidate ref-related functionality into git-refs
>
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
>
> Refactoring in order to reduce Git’s global state
>
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
>
> Machine-Readable Repository Information Query Tool
>
> - Mentor: Karthik
> - Co-mentor: Patrick
>
> Implement support for reftables in “dumb” HTTP transport
>
> - Mentor: Patrick
> - Co-mentor: Karthik
>
> -- >8 --
>
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.
>

>
> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
>
>
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.
>

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

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

> > 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.
> 
> It might be nice if we could refresh our microproject idea list too.
> Maybe we could add ideas related to removing the_repository or
> compiling with -Wsign-compare?

> I was wondering whether it might make sense to also move the list of
> microprojects into the Git project itself, e.g. as something like
> "Documentation/Projects.txt". This would make it easier for us to update
> the list of long-running projects whenever a new project is added and
> makes it easier for people to discover it.
>
> It would also help to document consensus in the Git project. The file
> would likely not always be 100% accurate, but it'd probably be more so
> compared to tracking it out of our tree.

> Patrick Steinhardt <ps@pks.im> writes:
> 
>> I was wondering whether it might make sense to also move the list of
>> microprojects into the Git project itself, e.g. as something like
>> "Documentation/Projects.txt". This would make it easier for us to update
>> the list of long-running projects whenever a new project is added and
>> makes it easier for people to discover it.
>>
>> It would also help to document consensus in the Git project. The file
>> would likely not always be 100% accurate, but it'd probably be more so
>> compared to tracking it out of our tree.
> 
> I am OK with the general idea, with one condition.  Each item in the
> list should have clear expiration date that makes it automatically
> eligible to be dropped from there.  Another uncurated list of random
> things is not what I want to add to and carry in my tree (the other
> uncurated list of random things being the set of topic branches that
> go stale without hitting 'next').
> 

> Hi Patrick and Junio,
> 
> On 22/01/25 02:05, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > I was wondering whether it might make sense to also move the list of
> > > microprojects into the Git project itself, e.g. as something like
> > > "Documentation/Projects.txt". This would make it easier for us to update
> > > the list of long-running projects whenever a new project is added and
> > > makes it easier for people to discover it.
> > > 
> > > It would also help to document consensus in the Git project. The file
> > > would likely not always be 100% accurate, but it'd probably be more so
> > > compared to tracking it out of our tree.
> > 
> > I am OK with the general idea, with one condition.  Each item in the
> > list should have clear expiration date that makes it automatically
> > eligible to be dropped from there.  Another uncurated list of random
> > things is not what I want to add to and carry in my tree (the other
> > uncurated list of random things being the set of topic branches that
> > go stale without hitting 'next').
> > 
> 
> Understood. We could certainly curate it from time to time. I wonder how
> we could set the timeline for a microproject idea, though. Would it make
> sense to fix a rough timeline such as 1 year or so and remove any idea
> whose age is more than the same?

> Also, the current list of ideas could roughly be seen here:
> 
> 
> https://github.com/git/git.github.io/blob/2025-microprojects/SoC-2025-Microprojects.md#ideas-for-microprojects
> 
> The topics are:
> 
>   - Fix Sign Comparison Warnings in Git's Codebase
> 
>   - Modernize Test Path Checking in Git's Test Suite
> 
>   - Add more builtin patterns for userdiff

>   - Avoid suppressing git's exit code in test scripts
> 
>   - Use unsigned integral type for collection of bits.
> 
>   - Modernize a test script
> 
> Do share your thoughts on which of these you find being relevant
> currently. That would help in preparing the first version of the in-tree
> project ideas list.

> > We could certainly curate it from time to time. I wonder how
> > we could set the timeline for a microproject idea, though. Would it make
> > sense to fix a rough timeline such as 1 year or so and remove any idea
> > whose age is more than the same?
>
> That'd be fine with me. Ideas don't necessarily have to get removed
> immediately, but may get "refreshed" in case they are still accurate.
> So personally I'd frame it less like an expiration date and more like
> the following:
>
>     Every topic added to the list will need to be checked regularly for
>     whether it is still accurate so that we can avoid an ever-growing
>     list of stale topics. As such, every topic needs to be accompanied
>     by a "best-before" date that indicates when the next check for this
>     topic is due.
>
>     It is the responsibility of the owner of the topic to determine
>     whether it is still accurate. This check should happen close to the
>     noted best-before date and come in the form of a patch that either
>     bumps the date in case it _is_ accurate, or alternatively removes
>     the topic from the list in case it is _not_ accurate anymore.
>
>     In case the topic owner does not send such a patch, contributors
>     other than the owner are encouraged to send a patch that removes the
>     topic, putting the owner into Cc.

> In any case, my proposal would be to add this paragraph or a variant
> thereof to a preamble explaining the purpose of the document as well as
> how to use it. This is somewhat similar to how our "BreakingChanges.txt"
> lays out expectations, which I think should be an inspiration for the
> new document, as well.

> > Also, the current list of ideas could roughly be seen here:
> >
> >
> > https://github.com/git/git.github.io/blob/2025-microprojects/SoC-2025-Microprojects.md#ideas-for-microprojects
> >
> > The topics are:
> >
> >   - Fix Sign Comparison Warnings in Git's Codebase
> >
> >   - Modernize Test Path Checking in Git's Test Suite
> >
> >   - Add more builtin patterns for userdiff
>
> This one doesn't feel like a sensible addition to me as it is
> open-ended.
>
> >   - Replace a run_command*() call by direct calls to C functions
>
> This one, too.

> >   - Avoid suppressing git's exit code in test scripts
> >
> >   - Use unsigned integral type for collection of bits.
> >
> >   - Modernize a test script
> >
> > Do share your thoughts on which of these you find being relevant
> > currently. That would help in preparing the first version of the in-tree
> > project ideas list.
>
> All the other topics are ongoing topics indeed and would be a good fit
> from my perspective.

> On Thu, Jan 30, 2025 at 8:32 AM Patrick Steinhardt <ps@pks.im> wrote:
> > This one doesn't feel like a sensible addition to me as it is
> > open-ended.
> >
> > >   - Replace a run_command*() call by direct calls to C functions
> >
> > This one, too.
> 
> We could put those two in a section for projects that are a bit larger
> than microprojects though. It might help those who have already worked
> on a microproject and want to do something a bit more involved.
> 
> It happens more and more often that people who want to apply to the
> GSoC or Outreachy start getting involved early, which is nice. They
> often have time, after their microproject and before working on their
> application, to work on something a bit more involved. So it would be
> nice if they could easily find something else to work on like those
> two ideas and others similar to them.

>     It is the responsibility of the owner of the topic to determine
>     whether it is still accurate. This check should happen close to the
>     noted best-before date and come in the form of a patch that either
>     bumps the date in case it _is_ accurate, or alternatively removes
>     the topic from the list in case it is _not_ accurate anymore.
>
>     In case the topic owner does not send such a patch, contributors
>     other than the owner are encouraged to send a patch that removes the
>     topic, putting the owner into Cc.
>
> Well... maybe it _is_ an expiration date. I dunno, I don't mind which
> exact term we use for it.

> I do not mind either word, either, but I have two small issues to
> raise:
>
>  - Is each topic "owned" by some specific person?  Would an owner
>    retires from the project, would the leftover bits go away with
>    the owner?

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I do not mind either word, either, but I have two small issues to
> > raise:
> >
> >  - Is each topic "owned" by some specific person?  Would an owner
> >    retires from the project, would the leftover bits go away with
> >    the owner?
> 
> I obviously meant "When an owner retires", but more importantly, I
> should have offered an alternative here, instead of just raising it
> as an issue.
> 
> How about making the rule a lot simpler?
> 
>     The expiration date kicks in _mechanically_, i.e. stale entries
>     are unconditionally dropped at the date, based solely on the
>     comparison between the timestamp and the wall clock.
> 
> People are free to advocate for its continued existence, and when
> such an effort achieves a concensus among then-active members of the
> community by the stated expiration date, a patch to update the
> entry's expiration date may be accepted, thereby prolonging its
> shelf life.  Unless such a thing happens before the expiration date
> comes, we will mechanically drop the entry.
> 
> Of course people _can_ resurrect an expired entry later as a new
> one when it seems appropriate.
> 
> That makes the decision to expire things from the list easy to make.

>> How about making the rule a lot simpler?
>> 
>>     The expiration date kicks in _mechanically_, i.e. stale entries
>>     are unconditionally dropped at the date, based solely on the
>>     comparison between the timestamp and the wall clock.
>> 
>> People are free to advocate for its continued existence, and when
>> such an effort achieves a concensus among then-active members of the
>> community by the stated expiration date, a patch to update the
>> entry's expiration date may be accepted, thereby prolonging its
>> shelf life.  Unless such a thing happens before the expiration date
>> comes, we will mechanically drop the entry.
>> 
>> Of course people _can_ resurrect an expired entry later as a new
>> one when it seems appropriate.
>> 
>> That makes the decision to expire things from the list easy to make.
>
> Works for me. Ideally, as any other topic, the retirement should be sent
> to the mailing list as a normal patch series so that people may chime in
> on the retirement and state reasons why they don't think that is a good
> idea.

> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> How about making the rule a lot simpler?
> >> 
> >>     The expiration date kicks in _mechanically_, i.e. stale entries
> >>     are unconditionally dropped at the date, based solely on the
> >>     comparison between the timestamp and the wall clock.
> >> 
> >> People are free to advocate for its continued existence, and when
> >> such an effort achieves a concensus among then-active members of the
> >> community by the stated expiration date, a patch to update the
> >> entry's expiration date may be accepted, thereby prolonging its
> >> shelf life.  Unless such a thing happens before the expiration date
> >> comes, we will mechanically drop the entry.
> >> 
> >> Of course people _can_ resurrect an expired entry later as a new
> >> one when it seems appropriate.
> >> 
> >> That makes the decision to expire things from the list easy to make.
> >
> > Works for me. Ideally, as any other topic, the retirement should be sent
> > to the mailing list as a normal patch series so that people may chime in
> > on the retirement and state reasons why they don't think that is a good
> > idea.
> 
> That is the complete opposite of the ideal from my point of view.
> The whole point of making the list items expire by default is that
> the onus is on those who want to have them on list to justify why
> these items must remain on the list.  A patch to remove an item that
> hasn't had anybody advocating for its retention shouldn't have to be
> chimed in to be supported.  There shouldn't even have to be a patch;
> that is what I mean by "stale entries expire mechanically by default".

> Patrick Steinhardt <ps@pks.im> writes:
> >     It is the responsibility of the owner of the topic to determine
> >     whether it is still accurate. This check should happen close to the
> >     noted best-before date and come in the form of a patch that either
> >     bumps the date in case it _is_ accurate, or alternatively removes
> >     the topic from the list in case it is _not_ accurate anymore.
> >
> >     In case the topic owner does not send such a patch, contributors
> >     other than the owner are encouraged to send a patch that removes the
> >     topic, putting the owner into Cc.
> >
> > Well... maybe it _is_ an expiration date. I dunno, I don't mind which
> > exact term we use for it.
> 
> I do not mind either word, either, but I have two small issues to
> raise:
> 
>  - Is each topic "owned" by some specific person?  Would an owner
>    retires from the project, would the leftover bits go away with
>    the owner?

> >>   - Fix Sign Comparison Warnings in Git's Codebase
> 
> This one I am not sure if it is even something we want more of; a
> careless "-Wsign-compare" squelching often makes the resulting code
> worse.

> I was wondering whether it might make sense to also move the list of
> microprojects into the Git project itself, e.g. as something like
> "Documentation/Projects.txt". This would make it easier for us to update
> the list of long-running projects whenever a new project is added and
> makes it easier for people to discover it.

> Patrick Steinhardt <ps@pks.im> writes:
> 
>> I was wondering whether it might make sense to also move the list of
>> microprojects into the Git project itself, e.g. as something like
>> "Documentation/Projects.txt". This would make it easier for us to update
>> the list of long-running projects whenever a new project is added and
>> makes it easier for people to discover it.
> 
> I wonder if this is better managed as either a separate tree (like
> the 'todo' branch that houses "What's cooking" reports among other
> things) with history disjoint from the main project, or even a
> separate Wiki?
>

> 
> It might be nice if we could refresh our microproject idea list too.
> Maybe we could add ideas related to removing the_repository or
> compiling with -Wsign-compare?
>

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

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

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

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

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

> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
> 
> 
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!
> 

> Christian, Patrick and Karthik,
> 
> As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
> 
> Ghanshyam and Jialuo,
> 
> As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
> 

> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
> 
> 
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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'm glad to announce that we've successfully been selected as a
> mentoring organization for GSoC this year[1]!

> Christian, Patrick and Karthik,
> 
> As you're already members of the organization kindly log in to the
> GSoC portal to read and accept this year's Program Rules and Org
> Member agreement. Let me know once that's done. I could then add you
> to this year's program.

> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
>
>
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!

>
>Christian, Patrick and Karthik,
>
>As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>
>Ghanshyam and Jialuo,
>
>As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>

> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
>
>
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!
>
> Christian, Patrick and Karthik,
>
> As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>

>
> Ghanshyam and Jialuo,
>
> As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>
> Let's look forward towards for a great summer this year! :-)
>
> [[ References ]]
>
> [1]: https://summerofcode.withgoogle.com/programs/2025/organizations/git
>
> --
> Sivaraam
>
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

> Hi Patrick, Christian, Karthik and Jialuo,
> 
> Thank you very much for your interest in volunteering as a mentor!
> 
> On Mon, Jan 20, 2025 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:
> 
> > I'd be happy to mentor this year again. A couple of ideas:
> >
> >
> Thank you for suggesting these ideas, Patrick! I've incorporated them into
> a draft
> ideas page for now. You can see them here:
> 
> https://git.github.io/SoC-2025-Ideas/

> Kindly suggest any corrections to the description, project size /
> difficulty as necessary.
> I've mentioned potential mentors based on what I'm aware of so far.
> 
> Patrick, Christian and Karthik, kindly mention the ideas that you're
> interested to
> mentor.
> 
> While I have not included them as of yet, I wonder if the following ideas
> which we
> had last year[1] could still be retained this year:
> 
> - Implement consistency checks for refs. The idea could be about
>    implementing further ref checks which Jialuo appears to be helping
>    out with. We could leave it if Jialuo prefers to continue working on
>    the same in a flow.

> On Mon, Jan 27, 2025 at 12:19:26PM +0530, Kaartic Sivaraam wrote:
> > Hi Patrick, Christian, Karthik and Jialuo,
> > 
> > Thank you very much for your interest in volunteering as a mentor!
> > 
> > On Mon, Jan 20, 2025 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:
> > 
> > > I'd be happy to mentor this year again. A couple of ideas:
> > >
> > >
> > Thank you for suggesting these ideas, Patrick! I've incorporated them into
> > a draft
> > ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> 
> Great, thanks a lot!
> 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary.
> > I've mentioned potential mentors based on what I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to
> > mentor.
> > 
> > While I have not included them as of yet, I wonder if the following ideas
> > which we
> > had last year[1] could still be retained this year:
> > 
> > - Implement consistency checks for refs. The idea could be about
> >    implementing further ref checks which Jialuo appears to be helping
> >    out with. We could leave it if Jialuo prefers to continue working on
> >    the same in a flow.
> 
> The biggest omission right now is the reftable backend, but that one I
> plan to work on myself in this release cycle.
> 

> On Mon, Jan 27, 2025 at 12:19:26PM +0530, Kaartic Sivaraam wrote:
>> While I have not included them as of yet, I wonder if the following ideas
>> which we
>> had last year[1] could still be retained this year:
>>
>> - Implement consistency checks for refs. The idea could be about
>>     implementing further ref checks which Jialuo appears to be helping
>>     out with. We could leave it if Jialuo prefers to continue working on
>>     the same in a flow.
> 
> The biggest omission right now is the reftable backend, but that one I
> plan to work on myself in this release cycle.
> 
> I'll leave it to Jialuo to decide whether there's anything else in this
> context that would make for a good GSoC project, as he's been the
> primary driving force here.
>

>> - Refactor git-bisect(1) to make its state self-contained
> 
> I'd rather remove that project. It would be nice to have it, but it
> feels too risky for a GSoC project, and we have better ones.
>