Subject: Re: Discuss GSOC: Refactoring in order to reduce Git’s global state

From: shejialuo <[email-masked]>
Date: Wed, 5 Mar 2025 19:41:41 +0800

On Wed, Mar 05, 2025 at 04:16:49PM +0530, Ayush Chandekar wrote:
> Hi,
> I have been studying Git's environment as I'm interested in working
> on the "Refactoring in order to reduce Git’s global state" project
> for GSOC 2025.

Glad to hear that.

> Some basic changes at the top of my mind are removing the
> 'have_git_dir()' and similar functions or shifting the
> 'local_repo_env[]' to the repository struct.

Although there are few callers calling `have_git_dir`, I don't think
it's a good idea to remove the `have_git_dir`. This is because we need
to reomove the dependency on `startup_info`. It's not an easy thing.

For `local_repo_env`, I don't dive into. So, maype Patrick could help
you here.

> I also read through the patches [1] and [2] submitted by Patrick.
> I can see that we also have to shift core.* into repo settings.

I somehow understand what you mean here. But "shift" may be not
accurate. When user sets the "core.*" in the command line or config
file, we will parse the setting and sets the _global_ state defined in
"environment.[ch]". We don't want to use these global variables, but
want to put these states into repo settings.

So, we do not shift core.* into repo settings, but shift the global
variables which are related to the "core.*" or other settings to repo
settings.

> I was planning to submit a small patch moving access to
> core.attributesfile into repo settings. However, before
> proceeding, I wanted to confirm if I am on the right track
> in understanding the project goals. Could you please suggest some
> more files I should look into??
> 

I think you could work on this but I don't think this would be a small
patch. You need some efforts to figure out the solution. You are on the
right direction.

However, it's hard to suggest which files you need to read. This is
because that for each global state, there are many files which may use
this global state. So, you'd better follow the call stack to know which
functions you need to change.

In conclusion, I somehow think that you could first think which states
you want to change. Try to figure out the most simplest global states.
Classify them by the complexity or difficulty thus you could write a
good proposal.

> Also are these patches ([1] and [2]) an example of how the project
> should be carried throughout the GSOC timeline?
> 

Exactly.

> Thanks,
> Ayush
> 
> [1] : https://lore.kernel.org/git/[email-masked]/
> [2] : https://lore.kernel.org/git/[email-masked]/

Thanks,
Jialuo