Ayush Chandekar <ayu.chandekar@xxxxxxxxx> writes: [snip] > 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 their local contexts. > > The general approach for handling a global variable begins with understanding > its purpose. This involves tracing its usage across the codebase and identifying > the subsystem it should belong to. If the variable is closely tied to > repository-related functionality, it may belong in struct repository or > struct repo_settings. Otherwise, it should be placed in a more suitable > context based on its scope. > > Additionally, it's important to review previous attempts or related patches > to understand past design decisions and ensure consistency with ongoing efforts. > Finally, the global instance is eliminated by relocating the variable into the > appropriate context and passing it through the relevant code paths. > > Example: Handling `is_bare_repository_cfg` > The variable `is_bare_repository_cfg` determines whether a repository is bare, > meaning it lacks a working directory. Since this property is fundamental to > how a repository functions, it should be placed in struct repository. > > I have also gone through the code paths and analyzed how this variable is > initialized. We can initialize it similarly to how hash_algo is set through > the repository format. The repository format already contains an `is_bare` > field, which we can use to set this variable inside struct repository. > > However, I still have some questions regarding why the is_bare_repository() > function checks for `repo->worktree` and why the `worktree struct` itself has > an `is_bare` variable. If a repository is considered bare when !repo->worktree > is true, the role of `worktree->is_bare` needs further clarification. I believe > that by engaging with the community, my understanding will become clearer. > I also went through [4] to see how John Cai's approach was. > > This is how we can also approach for other global variables. > Through multiple iterations, this approach will be refined based on feedback, > edge cases, and community input. > So the approach you suggest is to comb through the global variables and config and find new locations for them to be stored. While this is definitely a bunch chunk of the problem, shouldn't we also talk about how we can reduce usage of some of these variables? In particular, I'm wondering how you'd want to tackle 'the_repository' usage. There is some previous work done here, where Patrick added the '#define USE_THE_REPOSITORY_VARIABLE' definition which tracks usage of global variable and usage of them in different files. A possible approach which has been followed is to simply go from the bottom layers of the code upwards, cleaning up usage of global variables and ensuring we can remove '#define USE_THE_REPOSITORY_VARIABLE' from files. This is also the approach taken in some of the patches that you've linked. [snip]
Attachment:
signature.asc
Description: PGP signature
