Re: [GSoC] Microproject help
On Fri, Mar 29, 2024 at 11:57:31AM +0800, vk wrote:
Show 61 quoted lines
> 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?Yes. Generally, what I do is:
1. Check out the `master` branch.
2. Merge the topic branch you want to build upon into the `master`
branch. 3. Build your topic on top of that merge commit.
When sending the patches to the mailing list you would mention that dependency e.g. in the cover letter and then only send patches from the merge commit to the tip of your own topic branch.
Note though that, as Junio mentioned, this is becoming more involved than the typical microproject. You can of course still continue to work on it if you want to, but definitely feel free to switch to an "easier" target to work on.
Patrick
