Re: Git in GSoC 2025

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