quoted

Yep, since I encountered this while working on the patch, it fits well
in the Pre-GSoC section.
Moving it there would better show how I learned more about the
project's scope through
community feedback.

Yes, this is my intention. This represents your ability where you
interact with the community and get feedback. And this is what we want
to see.

Got it!

quoted

So, I should remove all the categorization stuff and just say that I
would focus on
each variable, discuss in the community whether it should belong in the struct
repo_settings/repo or not while sending patches?

I think you should put the categorization stuff into after-GSoC part.
Well, I don't think you could focus on _each_ variable. This is
impossible for you to talk about the way for _each_ variable. I somehow
think that you could just write the proposal about how to handle one or
two global variables.

Right, I can do that.

You already touch one setting "core.attributesfile" right? You may just
elaborate more in the proposal.

Yep!

quoted

I felt that keeping it general might seem vague, but that's the nature
of the project. Every variable
is unique and would need a different approach and outlining the
approach of each variable
in the proposal is not very feasible, as these decisions need to
happen collaboratively through
discussions in the community.

Yes, so you could firstly give how you want to handle the global
variables from top. And give some concrete examples to demonstrate your
idea.

Alright, will do.

I'll send a new iteration of the proposal soon.

Thank you so much for your inputs:)
Ayush

On Mon, Mar 31, 2025 at 7:47 PM shejialuo [off-list ref] wrote:

On Sat, Mar 29, 2025 at 03:24:05PM +0530, Ayush Chandekar wrote:

[snip]

quoted

quoted

quoted

One key challenge is determining which variables should be part of
`repo_settings` and which should remain separate. While working on the patch to
refactor access to `core.attributesfile`, I received feedback from Junio that not
all global variables should be blindly moved into the `repo_settings` struct.
This reinforced the need to carefully assess which variables belong in `repo_settings`
and which should be handled differently.

Yes, this is correct. I somehow think whether we should put this
paragraph into Pre-GSoC part? I think that you have found this when
adding a patch to remove one global variable. And thus by communicating
with the community, you have further understood that the requirement and
the detail of this project.

Yep, since I encountered this while working on the patch, it fits well
in the Pre-GSoC section.
Moving it there would better show how I learned more about the
project's scope through
community feedback.

Yes, this is my intention. This represents your ability where you
interact with the community and get feedback. And this is what we want
to see.

quoted

quoted

And in your plan, you should just say that we need to do this. Would
this be better?

So, I should remove all the categorization stuff and just say that I
would focus on
each variable, discuss in the community whether it should belong in the struct
repo_settings/repo or not while sending patches?

I think you should put the categorization stuff into after-GSoC part.
Well, I don't think you could focus on _each_ variable. This is
impossible for you to talk about the way for _each_ variable. I somehow
think that you could just write the proposal about how to handle one or
two global variables.

You already touch one setting "core.attributesfile" right? You may just
elaborate more in the proposal.

quoted

I felt that keeping it general might seem vague, but that's the nature
of the project. Every variable
is unique and would need a different approach and outlining the
approach of each variable
in the proposal is not very feasible, as these decisions need to
happen collaboratively through
discussions in the community.

Yes, so you could firstly give how you want to handle the global
variables from top. And give some concrete examples to demonstrate your
idea.

quoted

Should I still mention that once the project is complete, we could
consider structuring related
stuff if the community sees value in it.

You could, mention this in after GSoC part.

quoted

quoted

quoted

This plan is flexible and may be refined through multiple iterations as I receive
feedback from the community and reviewers.

Timeline:
---------

Pre-GSOC:
(Until 8 May)
-     Explore the codebase more, focusing on environment-related code paths.
-     Document how each global variable is used and how it can be moved to
      repository settings.
-     Study Git’s Coding Guidelines and the Pro Git Book to align with best practices.

----------

Community Bonding:
(May 8 - June 1)
-     Engage with mentors to discuss different environment variables, their
      dependencies, and the best approach for refactoring.
-     Finalize an implementation plan based on discussions.
-     Since I will be on summer vacation, I can start coding early and make progress
      on the project.

----------

Coding Period:
(June 2 - August 25)
-     Refactor global variables, replacing them with repository-scoped
      configurations.
-     Modify function signatures to pass `struct repository` explicitly instead
      of relying on `the_repository`.
-     Categorize variables into specialized structs to improve modularity and
      maintainability.

As I have said, this is a high-risk task. Categorization needs many
iterations. And we may do this after GSoC.

Yep, will update that.

Thanks for your review, again:)

Ayush

Thanks,
Jialuo