Re: [GSoC] Microproject help

[vk <g@vkabc.me>]

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 <g@vkabc.me> 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