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

[Patrick Steinhardt <ps@pks.im>]

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.

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

Thanks!

Patrick