From: vk Date: Fri, 29 Mar 2024 03:57:31 GMT Subject: Re: [GSoC] Microproject help Message-ID: <80f0bb12243eedbc4ad6580cb06abeb2@vkabc.me> In-Reply-To: On 2024-03-27 14:36, Patrick Steinhardt wrote: > On Tue, Mar 26, 2024 at 07:56:19PM +0800, vk wrote: >> On 2024-03-26 02:25, Karthik Nayak wrote: >> > vk writes: >> > >> > Hello! >> > >> > > Hello all, >> > > >> > > I'm Vk and I work as a software engineer. I am interested in >> > > contributing to git repository. Apologies for the late start as I only >> > > stumbled upon GSoC recently and git project interested me as I use it >> > > everyday at work and it would be meaningful for me to contribute to >> > > it. >> > > Even if I am not chosen, it will be great if I can start learning to >> > > contribute to git open source. >> > > >> > > For the microproject, I have looked into the lists for 2024 and it >> > > seems >> > > that all the projects have been taken except for `Replace a >> > > run_command*() call by direct calls to C functions`. However, it seems >> > > that the issue has been solved. The command I ran to search throughout >> > > the repo is `git grep 'run_command*('` and the search result returns >> > > run_command functions which I assume are essential. >> > > >> > >> > When I ran the same, I saw around 135 results. Are you saying that >> > they're all essential? >> > >> > For e.g. In `builtin/gc.c:maintenance_task_pack_refs`, shouldn't you be >> > able to replace the `run_command`? >> > >> >> My bad as the example uses `run_command_v_opt` and upon further >> inspection >> it seems that there might be similar situations like the example that >> can >> save an external process. However, for the maintenance_task_pack_refs, >> the >> command being run is `git pack-refs` which is a write process unlike >> the >> example which is a simple read only process of `git show-branch` to >> get the >> current commit? I will be searching the codebase for similar read only >> `run_command` and see if I can replace them. > > Hint: the `maintenance_task_pack_refs()` can in fact be converted to > use > `refs_pack_refs()` instead. I was briefly considering doing that in > [1], > but then didn't want to do such an unrelated refactoring in an already > long patch series. > > So if you decide to do that you should probably build on top of my > patch > series to avoid conflicts. The patch series is available e.g. at [2], > branch "ps/pack-refs-auto". So if you decide to give it a try you > should > build on top of that branch. Hello all, For the build on top of ps/pack-refs-auto, do I commit to this branch locally and get the diff for submitting the patch? Thank you