Editing GSoC Project Ideas

Editing GSoC Project Ideas

[Phillip Wood]

I'd be very grateful if someone with write access could please update 
the description of "Refactoring in order to reduce Git’s global state" 
[1] to stop recommending moving settings from `environment.c` into 
`struct repository_settings`. That struct was originally added to hold 
config settings that were already lazily parsed. We've had a number of 
submissions that move eagerly parsed config settings into that struct 
where an invalid config setting causes git to start dying in unexpected 
places when the lazy parsing fails.

The current wording of the suggested microproject does not mention any 
of the subtleties involved which sets students up to fail. A better 
suggestion would be for them to look at what Bello Caleb Olamide has 
been doing in their Outreach project [2].

I haven't been following Stolee's work [3] on "git conifg list --type" 
closely but I think it introduces some functions to parse config 
settings gently. Those functions might enable us to parse some config 
settings lazy where the functions using the lazily parsed settings are 
already set up to return a error. Doing that would require careful 
analysis and should not be a blanket recommendation.

Thanks

Phillip

[1] https://git.github.io/SoC-2026-Ideas/
[2] 
https://lore.kernel.org/48821a3848bef25c13038be8377ad73e7c17a924.1771258573.git.belkid98@gmail.com
[3] 
https://lore.kernel.org/pull.2044.v3.git.1771849615.gitgitgadget@gmail.com

Re: Editing GSoC Project Ideas

[Christian Couder]

Hi Phillip,

On Sun, Mar 1, 2026 at 3:26 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> I'd be very grateful if someone with write access could please update
> the description of "Refactoring in order to reduce Git’s global state"
> [1] to stop recommending moving settings from `environment.c` into
> `struct repository_settings`. That struct was originally added to hold
> config settings that were already lazily parsed. We've had a number of
> submissions that move eagerly parsed config settings into that struct
> where an invalid config setting causes git to start dying in unexpected
> places when the lazy parsing fails.

Yes, we should definitely update the description. Thanks for telling
us about this.

> The current wording of the suggested microproject does not mention any
> of the subtleties involved which sets students up to fail. A better
> suggestion would be for them to look at what Bello Caleb Olamide has
> been doing in their Outreach project [2].

Yeah, I agree. We should suggest that.

> I haven't been following Stolee's work [3] on "git conifg list --type"
> closely but I think it introduces some functions to parse config
> settings gently. Those functions might enable us to parse some config
> settings lazy where the functions using the lazily parsed settings are
> already set up to return a error. Doing that would require careful
> analysis and should not be a blanket recommendation.

I haven't followed Stolee's work either, but I will take a look.
Thanks for the pointer.

In the meantime, if you have concrete suggestions for change you can
submit one or more PRs to the https://github.com/git/git.github.io/
repo.

Thanks again anyway!

Re: Editing GSoC Project Ideas

[Kaartic Sivaraam]

+Cc Stolee

Hi Phillip,

On 02/03/26 03:48, Christian Couder wrote:
> 
> On Sun, Mar 1, 2026 at 3:26 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> I'd be very grateful if someone with write access could please update
>> the description of "Refactoring in order to reduce Git’s global state"
>> [1] to stop recommending moving settings from `environment.c` into
>> `struct repository_settings`. That struct was originally added to hold
>> config settings that were already lazily parsed. We've had a number of
>> submissions that move eagerly parsed config settings into that struct
>> where an invalid config setting causes git to start dying in unexpected
>> places when the lazy parsing fails.
> 
> Yes, we should definitely update the description. Thanks for telling
> us about this.
>

Indeed. Thank you for the suggestion. We've tried to tweak the 
description accordingly. Kindly check and let us know if it still needs 
any tweaks:

   https://git.github.io/SoC-2026-Ideas/

>> I haven't been following Stolee's work [3] on "git conifg list --type"
>> closely but I think it introduces some functions to parse config
>> settings gently. Those functions might enable us to parse some config
>> settings lazy where the functions using the lazily parsed settings are
>> already set up to return a error. Doing that would require careful
>> analysis and should not be a blanket recommendation.
> 
> I haven't followed Stolee's work either, but I will take a look.
> Thanks for the pointer.
>

I've not yet mentioned stolee's work in the tweak as it is a work in 
progress. I'll leave it for a future enhancement in case it is really 
worth mentioning the same.

> In the meantime, if you have concrete suggestions for change you can
> submit one or more PRs to the https://github.com/git/git.github.io/
> repo.
> 

Just to add to this, any patches via mailing-list are also welcome if 
that's preferred :-)

--
Sivaraam

Re: Editing GSoC Project Ideas

[Phillip Wood]

Hi Kaartic

On 02/03/2026 18:03, Kaartic Sivaraam wrote:
> +Cc Stolee
> 
> Hi Phillip,
> 
> On 02/03/26 03:48, Christian Couder wrote:
>>
>> On Sun, Mar 1, 2026 at 3:26 PM Phillip Wood 
>> <phillip.wood123@gmail.com> wrote:
>>>
>>> I'd be very grateful if someone with write access could please update
>>> the description of "Refactoring in order to reduce Git’s global state"
>>> [1] to stop recommending moving settings from `environment.c` into
>>> `struct repository_settings`. That struct was originally added to hold
>>> config settings that were already lazily parsed. We've had a number of
>>> submissions that move eagerly parsed config settings into that struct
>>> where an invalid config setting causes git to start dying in unexpected
>>> places when the lazy parsing fails.
>>
>> Yes, we should definitely update the description. Thanks for telling
>> us about this.
>>
> 
> Indeed. Thank you for the suggestion. We've tried to tweak the 
> description accordingly. Kindly check and let us know if it still needs 
> any tweaks:
> 
>    https://git.github.io/SoC-2026-Ideas/

Thanks for updating that, it is certainly much clearer.

>>> I haven't been following Stolee's work [3] on "git conifg list --type"
>>> closely but I think it introduces some functions to parse config
>>> settings gently. Those functions might enable us to parse some config
>>> settings lazy where the functions using the lazily parsed settings are
>>> already set up to return a error. Doing that would require careful
>>> analysis and should not be a blanket recommendation.
>>
>> I haven't followed Stolee's work either, but I will take a look.
>> Thanks for the pointer.
>>
> 
> I've not yet mentioned stolee's work in the tweak as it is a work in 
> progress. I'll leave it for a future enhancement in case it is really 
> worth mentioning the same.

That sounds sensible as none of us have actually thought through if it 
is useful yet.

>> In the meantime, if you have concrete suggestions for change you can
>> submit one or more PRs to the https://github.com/git/git.github.io/
>> repo.
>>
> 
> Just to add to this, any patches via mailing-list are also welcome if 
> that's preferred :-)

Thanks I'll bear that in mind

Phillip