From: Usman Akinyemi Date: Thu, 05 Nov 2026 00:01:49 GMT Subject: Re: [Outreachy][Proposal]: Reduce Git's global state to enable Git's libification[Outreachy][Proposal]: Reduce Git's global state to enable Git's libification Message-ID: In-Reply-To: On Wed, Nov 4, 2026 at 3:28 PM Srujith Poojary wrote: > > Hello Git community, > > Thank you for the guidance on sharing the proposal. > > I am resending my proposal inline so that reviewers can quote specific > sections and provide feedback more easily. > > I would appreciate feedback on the technical scope, implementation > approach, regression-testing strategy and feasibility of the proposed > work. > > Proposal: Reduce Git's global state to enable Git's libification > > 1. Introduction > > As a BCA graduate, I have a good foundation of programming and have > worked with some programming languages. I have practical experience > developing software projects and contributing to open source projects. > While learning how to use Git and GitHub for version control and > managing changes in my projects I became interested in using different > publicly available open source repositories. This led me to become > curious about how Git works internally, How its source code is > structured, and how its developers keep such a huge project going. > > This pushed me to look into the source code of Git. I learned about > the C concepts that are needed to understand the code such as > pointers, structures, functions and looking at how the different parts > code communicates with itself. I looked into the Git code related to > repositories and learned about concepts such as the_repository, struct > repository *repo, global state and explicit dependencies. This taught > me that when contributing to a well established open source project > there is more to it than just writing code. You need to understand the > existing functionality, look at past changes and ensure that the code > is tested properly. > > I made some contributions while preparing for this project. I made > changes to test scripts, test-path and safe integer arithmetic in > diff-delta. I worked on a submodule-related change involving > repository-specific commit abbreviations and made an updated patch > series for review. I gained practical experience of looking at > existing code, creating patches, testing and getting my code reviewed. > > When i got to know about this project is while watching videos on > YouTube about Git and contributing to open source projects I > discovered Outreachy. I submitted my initial application and looked > through the list of projects available. I found the Git project, > 'Reduce Git's global state to enable Git's libification'. As I was > already interested in Git and GitHub and had begun learning about C > programming, I decided to choose this project as it fit my interests. > I began preparing for this project by completing the microproject, > looking at Git's source code, looking into past changes and > researching potential areas to contribute to for my main project. > > I am interested to involved with this Outreachy internship project for You might want to change this line to something like: ""I am interested in contributing to this Outreachy internship project" > December 2026 as it will give me the opportunity to understand and > contribute to a key part of Git's internal design. I am interested in > understanding how to replace implicit dependencies on global state by > passing the required repository or index information explicitly. I > would like to learn how this can help make the code more testable, > maintainable and reusable. > > I hope to boost my C programming and problem solving skills during > this internship. I hope to make useful and thoroughly tested changes > to Git. I am happy to look into the existing implementation, talk to > maintainers, learn from code reviews and improve my work using > technical feedback and collaboration with community. > > 2. Understanding the Project > > 2.1 What is Git's global state? > > Global state is information stored in variables that can be accessed > by different parts of a program. A global variable is declared outside > a function, so more than one function can access it. In Git, global > variables are used to store and access information such as repository > details and environment settings. > > One important example in Git is the_repository. It is a global pointer > that gives access to repository information through a struct > repository object. Different parts of Git can use this pointer to > retrieve information about the repository currently in use. For > example, the_repository->index accesses that repository's index. > > The problem is that a function can access a global variable directly > instead of receiving the information it needs through its arguments. > This creates a hidden dependency because the function relies on > information that is not clear from its parameters. It can make the > function harder to understand and test with different repository > contexts, and harder to reuse independently. Reducing these hidden > dependencies is one reason Git is working to reduce its reliance on > global state. > > 2.2 What does libification mean? > > A software library refers to a set of code that can be used by other > programs to complete specific tasks. This means that we don’t need to > fully implement something from scratch in our application. > > Git was originally designed as a command line tool. This means that > different sections of code can access the same information using > global variables. Libification makes Git’s internal code more suitable > to be used as a library by other applications. This can be an issue > when trying to use Git’s internal code in other applications as it can > cause issues due to relying on global variables. > > To fix this we can pass the necessary information into the function > arguments. An example would be passing a struct repository pointer, > such as struct repository *repo, as an argument so that the function Passing a struct repository *repo as arguments to a function, while this is true, I believe passing the repo as an argument to the function is just a means to an end which you already mentioned, as you said the main goal is to remove the reliance of the codebase on the global "the_repository" and use the local "repo" instead. > can access a specific repository. Or passing a struct index_state > pointer, such as struct index_state *istate so that the function can > work with a specific index. This makes it clear what the function > **Output:** A technically justified follow-up contribution, or an > improved initial contribution. > > Week 11: Review and refine the implementation > I think you missed the blogging section. Thanks for your interest in the Git project and do not forget to submit your application on the Outreachy website. I believe you can edit until the final deadline hour. Usman.