From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail•com>
To: git@vger•kernel.org
Cc: gitster@pobox•com, christian.couder@gmail•com,
karthik.188@gmail•com, jltobler@gmail•com,
ayu.chandekar@gmail•com, siddharthasthana31@gmail•com,
lucasseikioshiro@gmail•com
Subject: Re: [GSOC] Discuss: Refactoring in order to reduce Git’s global state
Date: Tue, 24 Feb 2026 21:45:54 +0530 [thread overview]
Message-ID: <20260224161932.33080-1-shreyanshpaliwalcmsmn@gmail.com> (raw)
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
next prev parent reply other threads:[~2026-02-24 16:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 18:02 =?y?q?=5BGSOC=5D=20Discuss=3A=20Refactoring=20in=20order=20to=20reduce=20Git=E2=80=99s=20global=20state?= Shreyansh Paliwal
2026-02-19 18:17 ` [GSOC] Discuss: Refactoring in order to reduce global state Shreyansh Paliwal
2026-02-23 8:26 ` Shreyansh Paliwal
2026-02-24 13:40 ` [GSOC] Discuss: Refactoring in order to reduce Git’s " Karthik Nayak
2026-02-24 16:15 ` Shreyansh Paliwal [this message]
2026-03-04 14:57 ` Shreyansh Paliwal
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=20260224161932.33080-1-shreyanshpaliwalcmsmn@gmail.com \
--to=shreyanshpaliwalcmsmn@gmail$(echo .)com \
--cc=ayu.chandekar@gmail$(echo .)com \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jltobler@gmail$(echo .)com \
--cc=karthik.188@gmail$(echo .)com \
--cc=lucasseikioshiro@gmail$(echo .)com \
--cc=siddharthasthana31@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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