git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: shejialuo <shejialuo@gmail.com>
Cc: Ayush Chandekar <ayu.chandekar@gmail.com>, git@vger.kernel.org
Subject: Re: Discuss GSOC: Refactoring in order to reduce Git’s global state
Date: Fri, 7 Mar 2025 09:09:42 +0100	[thread overview]
Message-ID: <Z8qpxj2i3vFjJe4l@pks.im> (raw)
In-Reply-To: <Z8g4dTSFQDTi9ueU@ArchLinux>

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/

  reply	other threads:[~2025-03-07  8:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 10:46 Discuss GSOC: Refactoring in order to reduce Git’s global state Ayush Chandekar
2025-03-05 11:41 ` shejialuo
2025-03-07  8:09   ` Patrick Steinhardt [this message]
2025-03-07 15:44     ` Ayush Chandekar
2025-03-08  1:06       ` Ayush Chandekar
2025-03-07 14:14   ` Ayush Chandekar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8qpxj2i3vFjJe4l@pks.im \
    --to=ps@pks.im \
    --cc=ayu.chandekar@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=shejialuo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).