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

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

[Ayush Chandekar]

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

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

Thanks,
Ayush

[1] : https://lore.kernel.org/git/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/
[2] : https://lore.kernel.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/

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

[shejialuo]

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/20250303-b4-pks-objects-without-the-repository-v1-0-c5dd43f2476e@pks.im/
> [2] : https://lore.kernel.org/git/20250206-b4-pks-path-drop-the-repository-v1-0-4e77f0313206@pks.im/

Thanks,
Jialuo

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

[Patrick Steinhardt]

On Wed, Mar 05, 2025 at 07:41:41PM +0800, shejialuo wrote:
> 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.

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

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

[Ayush Chandekar]

Thanks for taking the time to respond!

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

Okay, got it.

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

I already submitted a patch quite a while ago: [1].
Thank you for clarifying how to approach this! It looks interesting to
me, and I'd love to give it a try.
I'll study more about it and hopefully submit a patch soon :)

Thanks,
Ayush

[1]: https://lore.kernel.org/git/20250202120926.322417-1-ayu.chandekar@gmail.com/

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

[Ayush Chandekar]

Hey,

> I already submitted a patch quite a while ago: [1].

By "patch" here, I mean patch for a microproject.

Best,
Ayush:)

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

[Ayush Chandekar]

Thanks for the response!

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

Oh, I will try to study more about it.

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

Right right, I went through it after your response, and understood
what you are saying.

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

Oh okay!
I was thinking of creating a poc patch to get a better understanding
of how to approach this during the timeline.

> > Also are these patches ([1] and [2]) an example of how the project
> > should be carried throughout the GSOC timeline?
> >
>
> Exactly.
>
Thank you so much!

(Sorry for the delayed reply, I have my university exams going on this
week :') )

Regards,
Ayush