From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com>
Date: Tue, 24 Feb 2026 16:15:54 GMT
Subject: Re: [GSOC] Discuss: Refactoring in order to reduce Git’s global state
Message-ID: <20260224161932.33080-1-shreyanshpaliwalcmsmn@gmail.com>
In-Reply-To: <CAOLa=ZSxkgGbWjYCu4DP269LtOdtn7Tcbz+DJH1ASyrGVXvb2A@mail.gmail.com>

> Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:
>
> > 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.

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

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