Shreyansh Paliwal [off-list ref] writes:

quoted

Hi everyone,

I have been around Git for some time and am interested in the “Refactoring
in order to reduce Git’s global state” project for GSoC 2026.

So far I have built Git from source, completed a microproject, and explored
some related areas in worktree and wt-status. I have also gone through the
blog posts by Ayush and Bello Olamide, which were very helpful in getting
to know about the ongoing/previous related to this. From what I gathered,

- In Outreachy, recent work has focused on moving core.attributesfile and
  core.sparseCheckout into local structs and also to handle the issue of
  lazy loading, but it is still a work in progress.

- In last year’s GSoC work, the focus included removing uses of
  the_repository and other globals across areas such as
  preload-index:(core_preload_index), builtin/prune:
  (repository_format_precious_objects), builtin/fmt-merge-msg:
  (merge_log_config).

Though I still have a few questions regarding the project for better clarity,

- Should the primary focus be on core library code rather than builtin?
  (ref. [1])

Phillip does make a good point, replacing global variable usage in the
library code is indeed more useful.

However cleanup of some of the global config variables, could involve
touching the builtin code.

Right, Got it.

quoted

- Is it preferable to approach the project file-wise (eg. cleanup of one
  file making it completely free of the_repository) or variable-wise (eg.
  identify one global state from environment.c and eliminate across the
  codebase)?

Depends, some variables (e.g. the_repository) are spread more broadly so
trying to go variable wise might not make much sense for them.

quoted

- Are there any globals which are best not to be removed currently?

For example, in editor.c there are mainly two globals,

- editor_program, which appears to be only used within the file and is not
  dependant on repository. So would it be preferable to remove it from
  environment.c and localize it within editor.c, move it into struct
  repository_settings / repo_config_values, or keep it as is?

Makes sense to localize it within editor.c. What's more important is to
understand that currently `editor_program` is setup inside
`git_default_core_config()`. What would the new flow look like?
Also with a global variable, its parsed once and available till
execution ends. Will that still be the case?

Hmm. I will see how we can localize editor_program while keeping the parsing
and availability like the global. I think Junio also pointed out something
related to lazy loading of global variables in some recent discussion, I will
look into that as well and will follow-up by an rfc patch on this, maybe that
will clear more things out.

quoted

- the_repository, there is only one instance in the function
  git_sequence_editor() which is used in editor.c which can be modified to
  pass struct repository down the callers but is also used in
  builtin/var.c, where a local repository instance is not available. In
  that case, would it be feasible to pass the_repository or is there any
  other way?

Yes, that's how I would tackle it. Moving dependency to upper layers is
a valid way to go about this, we do want to avoid this scenario if the
upper layer is already cleared of such variables and has access to an
alternative. In your case 'builtin/var.c' already uses 'the_repository',
so this should be acceptable.

Understood. That makes sense.

Thanks for the guidance,
Shreyansh