{"thread":{"id":"65024","subject":"=?y?q?=5BGSOC=5D=20Discuss=3A=20Refactoring=20in=20order=20to=20reduce=20Git=E2=80=99s=20global=20state?=","startedAt":"2026-02-19T18:12:17Z","lastAt":"2026-03-04T14:58:37Z","messageCount":6,"participants":["Shreyansh Paliwal","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"536426","messageId":"20260219181154.66814-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65024","inReplyTo":null,"subject":"=?y?q?=5BGSOC=5D=20Discuss=3A=20Refactoring=20in=20order=20to=20reduce=20Git=E2=80=99s=20global=20state?=","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-02-19T18:02:18Z","receivedAt":"2026-02-19T18:12:17Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"Hi everyone,\n\nI have been around Git for some time and am interested in the “Refactoring\nin order to reduce Git’s global state” project for GSoC 2026.\n\nSo far I have built Git from source, completed a microproject, and explored\nsome related areas in worktree and wt-status. I have also gone through the\nblog posts by Ayush and Bello Olamide, which were very helpful in getting\nto know about the ongoing/previous related to this. From what I gathered,\n\n- In Outreachy, recent work has focused on moving core.attributesfile and\n  core.sparseCheckout into local structs and also to handle the issue of\n  lazy loading, but it is still a work in progress.\n\n- In last year’s GSoC work, the focus included removing uses of\n  the_repository and other globals across areas such as\n  preload-index:(core_preload_index), builtin/prune:\n  (repository_format_precious_objects), builtin/fmt-merge-msg:\n  (merge_log_config).\n\nThough I still have a few questions regarding the project for better clarity,\n\n- Should the primary focus be on core library code rather than builtin?\n  (ref. [1])\n\n- Is it preferable to approach the project file-wise (eg. cleanup of one\n  file making it completely free of the_repository) or variable-wise (eg.\n  identify one global state from environment.c and eliminate across the\n  codebase)?\n\n- Are there any globals which are best not to be removed currently?\n\nFor example, in editor.c there are mainly two globals,\n\n- editor_program, which appears to be only used within the file and is not\n  dependant on repository. So would it be preferable to remove it from\n  environment.c and localize it within editor.c, move it into struct\n  repository_settings / repo_config_values, or keep it as is?\n\n- the_repository, there is only one instance in the function\n  git_sequence_editor() which is used in editor.c which can be modified to\n  pass struct repository down the callers but is also used in\n  builtin/var.c, where a local repository instance is not available. In\n  that case, would it be feasible to pass the_repository or is there any\n  other way?\n\nI have also surveyed files that use #define USE_THE_REPOSITORY_VARIABLE to\nroughly analyse the usage of globals, and I could make that much of the\nlibrary code is still dependant on the_repository, so could that be taken\non priority to reduce the usage of the_repository throughout the codebase.\n\nThanks,\nShreyansh\n\n[1]- https://lore.kernel.org/git/7b5dd0c4-0ca0-458e-89db-621a70dac9ae@gmail.com/\n"},{"id":"536428","messageId":"20260219181736.71467-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65024","inReplyTo":"20260219181154.66814-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC] Discuss: Refactoring in order to reduce global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-02-19T18:17:05Z","receivedAt":"2026-02-19T18:17:50Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"I think there was an issue with git send-email that is why the subject\nline seems malformed. Please ignore that.\n\n\n"},{"id":"536707","messageId":"20260223082616.1824407-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65024","inReplyTo":"20260219181154.66814-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC] Discuss: Refactoring in order to reduce global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-02-23T08:26:11Z","receivedAt":"2026-02-23T08:26:51Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"ping.\n"},{"id":"536971","messageId":"CAOLa=ZSxkgGbWjYCu4DP269LtOdtn7Tcbz+DJH1ASyrGVXvb2A@mail.gmail.com","threadId":"65024","inReplyTo":"20260219181154.66814-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC] Discuss: Refactoring in order to reduce Git’s global state","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-02-24T13:40:33Z","receivedAt":"2026-02-24T13:40:35Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:\n\n> Hi everyone,\n>\n> I have been around Git for some time and am interested in the “Refactoring\n> in order to reduce Git’s global state” project for GSoC 2026.\n>\n> So far I have built Git from source, completed a microproject, and explored\n> some related areas in worktree and wt-status. I have also gone through the\n> blog posts by Ayush and Bello Olamide, which were very helpful in getting\n> to know about the ongoing/previous related to this. From what I gathered,\n>\n> - In Outreachy, recent work has focused on moving core.attributesfile and\n>   core.sparseCheckout into local structs and also to handle the issue of\n>   lazy loading, but it is still a work in progress.\n>\n> - In last year’s GSoC work, the focus included removing uses of\n>   the_repository and other globals across areas such as\n>   preload-index:(core_preload_index), builtin/prune:\n>   (repository_format_precious_objects), builtin/fmt-merge-msg:\n>   (merge_log_config).\n>\n> Though I still have a few questions regarding the project for better clarity,\n>\n> - Should the primary focus be on core library code rather than builtin?\n>   (ref. [1])\n>\n\nPhillip does make a good point, replacing global variable usage in the\nlibrary code is indeed more useful.\n\nHowever cleanup of some of the global config variables, could involve\ntouching the builtin code.\n\n> - Is it preferable to approach the project file-wise (eg. cleanup of one\n>   file making it completely free of the_repository) or variable-wise (eg.\n>   identify one global state from environment.c and eliminate across the\n>   codebase)?\n>\n\nDepends, some variables (e.g. the_repository) are spread more broadly so\ntrying to go variable wise might not make much sense for them.\n\n> - Are there any globals which are best not to be removed currently?\n>\n> For example, in editor.c there are mainly two globals,\n>\n> - editor_program, which appears to be only used within the file and is not\n>   dependant on repository. So would it be preferable to remove it from\n>   environment.c and localize it within editor.c, move it into struct\n>   repository_settings / repo_config_values, or keep it as is?\n>\n\nMakes sense to localize it within editor.c. What's more important is to\nunderstand that currently `editor_program` is setup inside\n`git_default_core_config()`. What would the new flow look like?\nAlso with a global variable, its parsed once and available till\nexecution ends. Will that still be the case?\n\n> - the_repository, there is only one instance in the function\n>   git_sequence_editor() which is used in editor.c which can be modified to\n>   pass struct repository down the callers but is also used in\n>   builtin/var.c, where a local repository instance is not available. In\n>   that case, would it be feasible to pass the_repository or is there any\n>   other way?\n>\n\nYes, that's how I would tackle it. Moving dependency to upper layers is\na valid way to go about this, we do want to avoid this scenario if the\nupper layer is already cleared of such variables and has access to an\nalternative. In your case 'builtin/var.c' already uses 'the_repository',\nso this should be acceptable.\n\n> I have also surveyed files that use #define USE_THE_REPOSITORY_VARIABLE to\n> roughly analyse the usage of globals, and I could make that much of the\n> library code is still dependant on the_repository, so could that be taken\n> on priority to reduce the usage of the_repository throughout the codebase.\n>\n> Thanks,\n> Shreyansh\n>\n> [1]- https://lore.kernel.org/git/7b5dd0c4-0ca0-458e-89db-621a70dac9ae@gmail.com/\n"},{"id":"536980","messageId":"20260224161932.33080-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65024","inReplyTo":"CAOLa=ZSxkgGbWjYCu4DP269LtOdtn7Tcbz+DJH1ASyrGVXvb2A@mail.gmail.com","subject":"Re: [GSOC] Discuss: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-02-24T16:15:54Z","receivedAt":"2026-02-24T16:20:00Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"> Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:\n>\n> > Hi everyone,\n> >\n> > I have been around Git for some time and am interested in the “Refactoring\n> > in order to reduce Git’s global state” project for GSoC 2026.\n> >\n> > So far I have built Git from source, completed a microproject, and explored\n> > some related areas in worktree and wt-status. I have also gone through the\n> > blog posts by Ayush and Bello Olamide, which were very helpful in getting\n> > to know about the ongoing/previous related to this. From what I gathered,\n> >\n> > - In Outreachy, recent work has focused on moving core.attributesfile and\n> >   core.sparseCheckout into local structs and also to handle the issue of\n> >   lazy loading, but it is still a work in progress.\n> >\n> > - In last year’s GSoC work, the focus included removing uses of\n> >   the_repository and other globals across areas such as\n> >   preload-index:(core_preload_index), builtin/prune:\n> >   (repository_format_precious_objects), builtin/fmt-merge-msg:\n> >   (merge_log_config).\n> >\n> > Though I still have a few questions regarding the project for better clarity,\n> >\n> > - Should the primary focus be on core library code rather than builtin?\n> >   (ref. [1])\n> >\n>\n> Phillip does make a good point, replacing global variable usage in the\n> library code is indeed more useful.\n>\n> However cleanup of some of the global config variables, could involve\n> touching the builtin code.\n\nRight, Got it.\n\n> > - Is it preferable to approach the project file-wise (eg. cleanup of one\n> >   file making it completely free of the_repository) or variable-wise (eg.\n> >   identify one global state from environment.c and eliminate across the\n> >   codebase)?\n> >\n>\n> Depends, some variables (e.g. the_repository) are spread more broadly so\n> trying to go variable wise might not make much sense for them.\n>\n> > - Are there any globals which are best not to be removed currently?\n> >\n> > For example, in editor.c there are mainly two globals,\n> >\n> > - editor_program, which appears to be only used within the file and is not\n> >   dependant on repository. So would it be preferable to remove it from\n> >   environment.c and localize it within editor.c, move it into struct\n> >   repository_settings / repo_config_values, or keep it as is?\n> >\n>\n> Makes sense to localize it within editor.c. What's more important is to\n> understand that currently `editor_program` is setup inside\n> `git_default_core_config()`. What would the new flow look like?\n> Also with a global variable, its parsed once and available till\n> execution ends. Will that still be the case?\n\nHmm. I will see how we can localize editor_program while keeping the parsing\nand availability like the global. I think Junio also pointed out something\nrelated to lazy loading of global variables in some recent discussion, I will\nlook into that as well and will follow-up by an rfc patch on this, maybe that\nwill clear more things out.\n\n> > - the_repository, there is only one instance in the function\n> >   git_sequence_editor() which is used in editor.c which can be modified to\n> >   pass struct repository down the callers but is also used in\n> >   builtin/var.c, where a local repository instance is not available. In\n> >   that case, would it be feasible to pass the_repository or is there any\n> >   other way?\n> >\n>\n> Yes, that's how I would tackle it. Moving dependency to upper layers is\n> a valid way to go about this, we do want to avoid this scenario if the\n> upper layer is already cleared of such variables and has access to an\n> alternative. In your case 'builtin/var.c' already uses 'the_repository',\n> so this should be acceptable.\n\nUnderstood. That makes sense.\n\nThanks for the guidance,\nShreyansh\n"},{"id":"537783","messageId":"20260304145823.189440-1-shreyanshpaliwalcmsmn@gmail.com","threadId":"65024","inReplyTo":"20260224161932.33080-1-shreyanshpaliwalcmsmn@gmail.com","subject":"Re: [GSOC] Discuss: Refactoring in order to reduce Git’s global state","fromName":"Shreyansh Paliwal","fromEmail":"shreyanshpaliwalcmsmn@gmail.com","sentAt":"2026-03-04T14:57:11Z","receivedAt":"2026-03-04T14:58:37Z","isPatch":false,"sender":{"key":"shreyanshpaliwalcmsmn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152720574?v=4"},"body":"Hi Karthik,\n\nFollowing up on this, I recently sent a patch on `editor_program` [1],\nbut the discussion hasn’t reached a clear conclusion yet. I would really\nappreciate your thoughts and feedback on it including what you think\nwould be the most appropriate way forward.\n\nThanks,\nShreyansh\n\n[1]- https://lore.kernel.org/git/20260301105228.1738388-1-shreyanshpaliwalcmsmn@gmail.com/\n"}]}