Re: [GSoC][Draft Proposal v3] Refactoring in order to reduce Git's global state

>
> -- Approach
>
> The task at hand goes beyond simply repackaging the global variables
> into the struct repository structure. Based on my recent experience
> refactoring setup.c, I realized that libification requires careful
> management of variable lifecycles and api boundaries:
>
>      [ Current ]
>      Core functions --------reads-------> Global variables (via getenv)
>                                           [Thread unsafe]
>
>      [ Target ]
>      Core functions ----passes context--> struct repository
>                                                  | owns
>                                                  v
>                                           struct git_env
>
> Although the principle is simple, the scope of changes is extensive. The
> following three-step approach can serve as a guiding principle for it:
>
>    1. Identify isolated environment variables currently residing in the
>       global scope. Introduce a dedicated structure to hold these states,
>       e.g. `struct git_env` within the `struct repository`.

>    2. Instead of blindly passing struct repository *repo down into every
>       single low-level library function, bubbling the dependency up is
>       the true goal. External callers of the functions must be carefully
>       audited to prevent regressions.
>    3. Safely remove the old global variables and macro definitions. Tools
>       such as AddressSanitizer can be helpful to ensure that the new
>       struct-based lifecycle introduces zero memory leaks.

>       New data flow might need to be designed to maintain the lazy-
>       loading efficiency.
>
> Additionally, given the anticipated high volume of commits, we must
> ensure each patch is independent and atomic, preventing any
> user-untraceable or unexplainable bugs from occurring in the codebase at
> any state.
>
>
> AVAILABILITY
> ------------
> Fortunately, my summer vacation coincides with the GSoC work period.
> I will treat this project as my primary focus, dedicating a minimum of
> 35 hours per week. If needed, I can work a 9-to-5 schedule.
>
> I will have a significant head start to draft RFC patches before the
> official coding period even begins. Having this buffer period allows me
> to go through the rigorous code review process within the Git community
> with greater ease.
>
>
> TIMELINE & MILESTONES
> ---------------------
> Considering the differences between this project and other projects on
> the idea list, rather than hoarding massive changes, I will submit
> 3-to-5-patch series frequently to respect reviewers' time and maintain a
> steady velocity.
>
> Below is the tentative schedule I have prepared for myself:
>
> * Community Bonding (May 1 - May 25): Planning & RFC
>    - May 1 - May 7: Wrap up university finals. Discuss and finalize the
>      prioritized list of subsystems with my mentor.
>    - May 8 - May 25: Define the core context container. Draft and submit
>      the initial RFC patch series for this new data structure.
>

> * Phase 1 (May 26 - July 10): Foundation
>    - Weeks 1-2: Plumb the context pointer (`struct repository *repo`)
> through call chains for simple variables (e.g., boolean flags or integer
> configs).
>    - Weeks 3-4: Audit and update external callers to use the new API.
>    - Weeks 5-6: Submit the first major refactoring patch series. Address
>      mailing list feedback and resolve merge conflicts. (Midterm Evaluation)
>
> * Phase 2 (July 11 - August 18): Complex Migration & Cleanup
>    - Weeks 7-8: Refactor higher-complexity variables (e.g., path-related
> globals).
>    - Weeks 9-10: Compile the codebase with AddressSanitizer and run the
> full test suite to execute strict memory leak checks.
>    - Weeks 11-12: Remove unused global macro definitions and static
> variables. Update internal documentation and write the final GSoC report.
>
> (The above is for reference only. Personally, I always finish tasks
> faster than planned 😉)
>
>
> ~$ git checkout HEAD@{postGSoC}
> -------------------------------
> This past month since joining the Git community has been the most
> enjoyable month of my programming journey. To quote a close friend of
> mine (who is applying for the Neovim GSoC project):
>
>    "Only fools chase trends; open source is the game for the brave."
>
> The words may be blunt, but the logic holds true. This statement surely
> resonates with me (and maybe many other GSoC contributors): our passion
> for code and open-source drives us forward.
>
> Even if I didn't make the cut, so what? ~$ git reset --hard...
> Just kidding. The Git codebase is far too interesting to abandon now.
>
> -------------------------------------------------------------------------
> Changes since V3:
>
>   - Based on reviewing last year's contributors' changes and recent
> experience modifying setup.c, additional descriptions have been added to
> the synopsis & approach section.