Re: [GSOC] [PROPOSAL V1]: Refactoring in order to reduce Git’s global state

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

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

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

>
> On Sat, Mar 29, 2025 at 03:24:05PM +0530, Ayush Chandekar wrote:
>
> [snip]
>
> > > > 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.
>
> > >
> > > 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.
>
> > 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.
>
> > 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.
>
> > > > 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