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

From: Patrick Steinhardt <ps@pks.im>
Date: Mar 7, 2025, 08:09 UTC
Message-ID: <Z8qpxj2i3vFjJe4l@pks.im>
In-Reply-To: <Z8g4dTSFQDTi9ueU@ArchLinux>

On Wed, Mar 05, 2025 at 07:41:41PM +0800, shejialuo wrote:

Show 18 quoted lines

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

Yeah, things depending on `startup_info` are definitely a more involved thing to address, and I wouldn't necessarily recommend it for the initial batch of refactorings. I'd recommend to rather focus on some of the global variables we have in "environment.c" that store configuration values, which are generally a bit easier to tackle.

Also note that `local_repo_env[]` is nothing that we need to adapt. It only stores a couple of environment variable names and does not have any state, so it's perfectly fine to keep that variable.

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

Yup, exactly, this is what I mention above.

Show 10 quoted lines

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

It would be a bit more involved than a typical microproject, but I don't think it's particularly bad. It would involve a couple of steps:

  - Investigate all users of the `git_attributes_file` global variable
    and how they interact with the variable.

  - Adapt `git_attr_global_file()` so that it knows to not only handle
    the fallback value of `xdg_config_home("attributes")`, but also
    knows to first read the value from the config.

  - Adapt `git_attr_global_file()` so that it accepts a repository as
    parameter so that it doesn't need to depend on `the_repository`.
    This will also require you to adapt all callers.

You _can_ use this as a microproject, but as said it's a bit more involved than what we'd expect. Which isn't necessarily bad if you manage to pull it off, but might make for a bit of a steep learning curve.

Alternatively, I'd recommend to read through [1] to learn about the application phase in general and [2] for recommendations for a couple of microprojects which are easier than the project you have picked :)

Patrick

[1]: https://git.github.io/General-Microproject-Information/ [2]: https://git.github.io/SoC-2025-Microprojects/