> > This project aims to refactor Git’s environment handling by relocating > > these global variables into appropriate local contexts primarily into > > `struct repository` and `struct repo_settings`. This change will not > > I think we could just improve this statement better. Some global > variables may only apply to one subsystem or two subsystems. In such > situations, we may just put the global variable into their own context > but not the "struct repository" or "struct repo_settings". Right, I was generalizing in my statement, but I agree that some global variables may belong in subsystem-specific contexts rather than `struct repository` or `struct repo_settings`. I'll make sure to account for that distinction in my proposal and implementation. > > > > Proposed Plan: > > -------------- > > > > I have been reviewing global variables across the codebase to understand their > > dependencies and impact. To do this, I examined `config.c` and cross-referenced > > it with `environment.c` to see how these variables are currently managed. The > > goal of this project is to eliminate global variables by moving their > > configurations into repository-specific settings. This involves: > > > > - Identifying all occurrences of these global variables. > > > > - Removing dependencies on `the_repository`. > > > > - Updating function signatures to pass `struct repository` explicitly. > > > > When reading this, I feel a little wired because I think in [1], you > have already realized that we should move some global variables to some > specific subsystems. > > [1] https://public-inbox.org/git/20250310151048.69825-1-ayu.chandekar@xxxxxxxxx/ > I see your point. I was generalizing again, but I’ll make sure to clarify this distinction in my proposal. Thanks for pointing it out! > > - Replacing global variable references with repository-scoped configurations. > > > > Instead of adding all variables directly into `repo_settings`, we can group > > related variables into specialized structs (e.g., `performance_config`, > > `behaviour_config`, `whitespace_config`) and embed these within `repo_settings`. > > This approach ensures a more modular and maintainable design while keeping > > `repo_settings` manageable. > > > > I have also created a diagram explaining this structure in [10]. > > > > With this approach, I can structure the patch series by grouping the refactoring > > of related variables within specific structs. This will help maintain a clean and > > organized codebase while also making the development and review process more > > systematic and efficient. > > > > Yes, it's a good idea to use sub-structure to make the code be cleaner. > However, from my own experience when being a GSoC student, we should not > consider about this due to that we will over-engineer this. > > You need a lot of time and effort to convince the community why the > design is good and why we should put this variable into this > sub-structure. > > Instead, you'd better focus on which variables you want to remove > firstly. And how do you try to remove them with some simple steps. This > would make you more concentrate on the jobs you need to do and reduce > the risk. > That makes sense. My intent was to provide a structured approach, but I could see how it it may introduce unnecessary complexity at this stage. I'll focus on identifying and managing the global variables before considering additional structuring. I think this is something which can be done at the end of the project. That is, once all the variables are handled, they can then be set into specific structures, if needed. > > One key challenge is determining which variables should be part of > > `repo_settings` and which should remain separate. While working on the patch to > > refactor access to `core.attributesfile`, I received feedback from Junio that not > > all global variables should be blindly moved into the `repo_settings` struct. > > This reinforced the need to carefully assess which variables belong in `repo_settings` > > and which should be handled differently. > > > > Yes, this is correct. I somehow think whether we should put this > paragraph into Pre-GSoC part? I think that you have found this when > adding a patch to remove one global variable. And thus by communicating > with the community, you have further understood that the requirement and > the detail of this project. Yep, since I encountered this while working on the patch, it fits well in the Pre-GSoC section. Moving it there would better show how I learned more about the project's scope through community feedback. > > And in your plan, you should just say that we need to do this. Would > this be better? > So, I should remove all the categorization stuff and just say that I would focus on each variable, discuss in the community whether it should belong in the struct repo_settings/repo or not while sending patches? I felt that keeping it general might seem vague, but that's the nature of the project. Every variable is unique and would need a different approach and outlining the approach of each variable in the proposal is not very feasible, as these decisions need to happen collaboratively through discussions in the community. Should I still mention that once the project is complete, we could consider structuring related stuff if the community sees value in it. > > This plan is flexible and may be refined through multiple iterations as I receive > > feedback from the community and reviewers. > > > > Timeline: > > --------- > > > > Pre-GSOC: > > (Until 8 May) > > - Explore the codebase more, focusing on environment-related code paths. > > - Document how each global variable is used and how it can be moved to > > repository settings. > > - Study Git’s Coding Guidelines and the Pro Git Book to align with best practices. > > > > ---------- > > > > Community Bonding: > > (May 8 - June 1) > > - Engage with mentors to discuss different environment variables, their > > dependencies, and the best approach for refactoring. > > - Finalize an implementation plan based on discussions. > > - Since I will be on summer vacation, I can start coding early and make progress > > on the project. > > > > ---------- > > > > Coding Period: > > (June 2 - August 25) > > - Refactor global variables, replacing them with repository-scoped > > configurations. > > - Modify function signatures to pass `struct repository` explicitly instead > > of relying on `the_repository`. > > - Categorize variables into specialized structs to improve modularity and > > maintainability. > > As I have said, this is a high-risk task. Categorization needs many > iterations. And we may do this after GSoC. Yep, will update that. Thanks for your review, again:) Ayush
