Re: [GSOC] [PROPOSAL v2]: Refactoring in order to reduce Git’s global state

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