[GSoC] Microproject help

[GSoC] Microproject help

[vk]

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.

If there is any low hanging fruits that you can suggest to me for the 
microproject, that will be great. I will also be searching throughout 
the mailing list to see if there are any potential microproject to work 
on.

Best Regards,
Vk

Re: [GSoC] Microproject help

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

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`?

>
> If there is any low hanging fruits that you can suggest to me for the
> microproject, that will be great. I will also be searching throughout
> the mailing list to see if there are any potential microproject to work
> on.
>
> Best Regards,
> Vk

I also see the other microprojects are still applicable, since most of
them have multiple occurrences throughout the code.

Wish you the best.
- Karthik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: [GSoC] Microproject help

[Eric Sunshine]

On Mon, Mar 25, 2024 at 11:40 AM vk <g@vkabc.me> wrote:
> 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.
>
> If there is any low hanging fruits that you can suggest to me for the
> microproject, that will be great. I will also be searching throughout
> the mailing list to see if there are any potential microproject to work
> on.

Searching the mailing list for "#leftoverbits"[1] can be a good way to
discover little tasks which may be suitable for a GSoC microproject.

[1]: https://lore.kernel.org/git/?q=%23leftoverbits

Re: [GSoC] Microproject help

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Mon, Mar 25, 2024 at 11:40 AM vk <g@vkabc.me> wrote:
>> 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.
>>
>> If there is any low hanging fruits that you can suggest to me for the
>> microproject, that will be great. I will also be searching throughout
>> the mailing list to see if there are any potential microproject to work
>> on.
>
> Searching the mailing list for "#leftoverbits"[1] can be a good way to
> discover little tasks which may be suitable for a GSoC microproject.
>
> [1]: https://lore.kernel.org/git/?q=%23leftoverbits

True, but with a caveat that they may range from "low hanging fruit"
to "too hard, let's punt".  After seeing the anonymous questioners'
question, I did go to that query page (actually I qualified the
query further to list only the ones I gave the mark) and decided not
to suggest it because I found that many recent ones are harder than
"trivial changes suitable for a practice material to go through the
review cycles" X-<.

Thanks.

Re: [GSoC] Microproject help

[Eric Sunshine]

On Mon, Mar 25, 2024 at 5:23 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > On Mon, Mar 25, 2024 at 11:40 AM vk <g@vkabc.me> wrote:
> >> If there is any low hanging fruits that you can suggest to me for the
> >> microproject, that will be great. I will also be searching throughout
> >> the mailing list to see if there are any potential microproject to work
> >> on.
> >
> > Searching the mailing list for "#leftoverbits"[1] can be a good way to
> > discover little tasks which may be suitable for a GSoC microproject.
>
> True, but with a caveat that they may range from "low hanging fruit"
> to "too hard, let's punt".  After seeing the anonymous questioners'
> question, I did go to that query page (actually I qualified the
> query further to list only the ones I gave the mark) and decided not
> to suggest it because I found that many recent ones are harder than
> "trivial changes suitable for a practice material to go through the
> review cycles" X-<.

Since the purpose of a GSoC microproject is to familiarize the
candidate with the project's mailing-list workflow and to give the
GSoC mentors a feel for how the candidate interacts, perhaps the
easiest suggestion would be the old fallback of having the candidate
look for a single test script which still uses `test -f` or `test -e`
or such, and converting that to use one of the test_path_foo()
functions from t/test-lib-functions.sh.

Re: [GSoC] Microproject help

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> Since the purpose of a GSoC microproject is to familiarize the
> candidate with the project's mailing-list workflow and to give the
> GSoC mentors a feel for how the candidate interacts, perhaps the
> easiest suggestion would be the old fallback of having the candidate
> look for a single test script which still uses `test -f` or `test -e`
> or such, and converting that to use one of the test_path_foo()
> functions from t/test-lib-functions.sh.

During today's discussion, we came up another interesting one.

    Follow one of our three tutorial documents to the letter to see
    if they need adjusting, and come up with a set of patches to
    adjust them.

This kills a few birds with a stone.

 - The student has to be familiar with the codebase and MyFirst
   tutorials are meant as a gentle "dip your toes in the water"
   introduction.  Following the examples and copy-pasting code
   snippet and trying to build would be useful exercise for GSoC
   candidates by itself.

 - These tutorials, unfortunately, haven't been maintained as well
   as they should have been, and some do not compile any longer due
   to API changes, header shuffling, etc.  Identifying such breakages
   and reporting them as bugs is already useful by itself, even if
   the student does not manage to fix them.

 - But if the GSoC student can learn to address such a bug (which
   requires use of "git log" and "git blame" to spelunk where the
   breakage happened, after which it would be obvious what the right
   fix would be), that is valuable exercise by itself, even if it
   does not reach the "patch submission" stage.

 - And of course, the result of such a work can go through the usual
   patch review cycle, which would serve as a microproject.

Hmm?

Re: [GSoC] Microproject help

[Eric Sunshine]

On Mon, Mar 25, 2024 at 5:58 PM Junio C Hamano <gitster@pobox.com> wrote:
> During today's discussion, we came up another interesting one.
>
>     Follow one of our three tutorial documents to the letter to see
>     if they need adjusting, and come up with a set of patches to
>     adjust them.
>
> This kills a few birds with a stone.
>
>  - The student has to be familiar with the codebase and MyFirst
>    tutorials are meant as a gentle "dip your toes in the water"
>    introduction.  Following the examples and copy-pasting code
>    snippet and trying to build would be useful exercise for GSoC
>    candidates by itself.
>
>  - These tutorials, unfortunately, haven't been maintained as well
>    as they should have been, and some do not compile any longer due
>    to API changes, header shuffling, etc.  Identifying such breakages
>    and reporting them as bugs is already useful by itself, even if
>    the student does not manage to fix them.
>
>  - But if the GSoC student can learn to address such a bug (which
>    requires use of "git log" and "git blame" to spelunk where the
>    breakage happened, after which it would be obvious what the right
>    fix would be), that is valuable exercise by itself, even if it
>    does not reach the "patch submission" stage.
>
>  - And of course, the result of such a work can go through the usual
>    patch review cycle, which would serve as a microproject.
>
> Hmm?

That sounds like a reasonable project, as well.

Re: [GSoC] Microproject help

[vk]

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.

Thank you

Re: [GSoC] Microproject help

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

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.

Patrick

[1]: https://lore.kernel.org/git/cover.1711360631.git.ps@pks.im/
[2]: https://github.com/gitster/git.git

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [GSoC] Microproject help

[vk]

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

Re: [GSoC] Microproject help

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> 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.

As the microproject is a learning experience for skills to work well
with others, we may want to suggest an area where there won't be
much conflicts, i.e. skill to find an area that are relatively
quiescent to avoid stepping each other's toes.

To be quite honest, I'd rather not to see a task that uses
run_command() API and gets done in safe process isolation turned
into an internal call by pure amateurs, unless competent mentors
go through the change with fine toothed comb and make sure there are
no unintended consequences and side effects of doing it in process.
This is especially true for microprojects, where the primary focus
is about learning the process of contribution and working with the
community, and not about learning the existing codebase and API.

Thanks.

Re: [GSoC] Microproject help

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Thu, Mar 28, 2024 at 10:46:35PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 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.
> 
> As the microproject is a learning experience for skills to work well
> with others, we may want to suggest an area where there won't be
> much conflicts, i.e. skill to find an area that are relatively
> quiescent to avoid stepping each other's toes.
> 
> To be quite honest, I'd rather not to see a task that uses
> run_command() API and gets done in safe process isolation turned
> into an internal call by pure amateurs, unless competent mentors
> go through the change with fine toothed comb and make sure there are
> no unintended consequences and side effects of doing it in process.
> This is especially true for microprojects, where the primary focus
> is about learning the process of contribution and working with the
> community, and not about learning the existing codebase and API.

That's a fair remark indeed. I wonder whether we should remove this
microproject altogether.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [GSoC] Microproject help

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

On Fri, Mar 29, 2024 at 11:57:31AM +0800, vk wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]