Re: [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state

[Arnav Bhate <bhatearnav@gmail.com>]

Patrick Steinhardt <ps@pks.im> writes:
> On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote:
> [snip]
>> ## Proposed Plan
>>
>> - Identifying all occurences of `the_repository` and updating them to
>>   use a `struct repository` passed to the function.
> 
> I think that might be overly ambituous :) After all we're talking about
> ~3500 occurrences, and it won't be feasible to replace them all in the
> couple of months. This is rather a multi-year project, and one that has
> already been going on for quite a while.
> 
>> - Identifying global variables that should be moved and identifying
>>   suitable locations, some could be moved directly into
>>   `struct repository`, some in its sub-structs that already exist and
>>   some in newly created sub-structs.
> 
> Likewise, I would recommend to properly scope _which_ variables you want
> to replace. There's a ton of global state, so you should try to limit
> the project to a reasonable workload.

I could do all the global variables in environment.c. I feel like that
is doable. Once I am finished with that, I could start replacing
the_repository.

>> - Identifying and updating occurences of these variables to reference
>>   their new locations.
>>
>> It makes sense that all the variables need not be in the same struct, as
>> separation would keep the codebase organised, and thus easier to
>> maintain. It would also make it easier to introduce these changes
>> systematically, as a group of related variables, combined together in a
>> struct, could be introduced in a single patch series.
>>
>> ### Timeline
>>
>> #### Pre-GSoC (Until May 8)
>>
>> - Explore the codebase, identifying global variables and how they are
>>   used.
>>
>> - Start to identify suitable locations for global variables.
>>
>> #### Community Bonding Period (May 8 - June 1)
>>
>> - Interact with mentor, discussing best ways to refactor various
>>   variables and make a plan based on that.
>>
>> - If time is left, start coding early, as my summer break will have
>>   started.
>>
>> #### Coding Period (June 2 - August 25)
>>
>> - Modify functions to add an `struct repository` argument where they
>>   depend on `the_repository` and replace all occurences of it.
>>
>> - Move global variables to their new locations in various structs,
>>   and refactor functions that depend on them to use their new locations.
> 
> In large-scale projects like these it typically makes sense to work in
> batches. Instead of having three separate phases to "define the
> problem", "develop the solution" and "deploy the improvement" I would
> strongly encourage you to define and tie together smaller batches of
> work.

What I meant is, before coding started, I want to finalise all the new
locations for the global variables with my mentor, then I would actually
modify the code in batches, struct-by-struct. Are you suggesting that
the new locations not be finalised beforehand, or are we misinterpreting
each other?

> Thanks!
> 
> Patrick

-- 
Regards,
Arnav Bhate
(He/Him)