[GSoC] My Git Dev Blog – Week 11

[GSoC] My Git Dev Blog – Week 11

[Atharva Raykar]

(Resent this email, because it bounced off the list again. My new config is
still a bit janky, so bear with me.)

Hi all,

Here’s my weekly Git Blog.

Preview:

- Project progress: where I discuss a rough plan for making ’git submodule’ a
  true builtin.

- Reflections: A summary of last week’s survey answers [1][2], and an
  explanation of my own slightly weird email setup that was borne out of the
  troubles I had in the last week.

[1] <https://lore.kernel.org/git/90b6bd2d-71e1-b8af-e027-8023f8d4f14c@gmail.com/>
[2] <https://atharvaraykar.me/gitnotes/week10#the-mailing-list-developer-workflow>

Have a great week!
---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

Re: [GSoC] My Git Dev Blog – Week 11

[Atharva Raykar]

Welp. I forgot the actual link to the blog.

Here it is:
https://atharvaraykar.me/gitnotes/week11

Atharva Raykar <raykar.ath@gmail.com> writes:

> (Resent this email, because it bounced off the list again. My 
> new config is
> still a bit janky, so bear with me.)
>
> Hi all,
>
> Here’s my weekly Git Blog.
>
> Preview:
>
> - Project progress: where I discuss a rough plan for making ’git 
> submodule’ a
>   true builtin.
>
> - Reflections: A summary of last week’s survey answers [1][2], 
> and an
>   explanation of my own slightly weird email setup that was 
>   borne out of the
>   troubles I had in the last week.
>
> [1] 
> <https://lore.kernel.org/git/90b6bd2d-71e1-b8af-e027-8023f8d4f14c@gmail.com/>
> [2] 
> <https://atharvaraykar.me/gitnotes/week10#the-mailing-list-developer-workflow>
>
> Have a great week!
> ---
> Atharva Raykar
> ಅಥರ್ವ ರಾಯ್ಕರ್
> अथर्व रायकर

Re: [GSoC] My Git Dev Blog – Week 11

[Christian Couder]

On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar <raykar.ath@gmail.com> wrote:

> Here it is:
> https://atharvaraykar.me/gitnotes/week11

Great, thanks!

> > Preview:
> >
> > - Project progress: where I discuss a rough plan for making ’git
> > submodule’ a
> >   true builtin.

So your plan is the following:

  - Rename git-submodule.sh to git-submodule-legacy.sh.
  - Create builtin/submodule.c, that will read from a config switch
called ‘submodule.useBuiltin’. If this is set to false, just call the
legacy shell script, else use the builtin versions.
  - Copy the functions from builtin/submodule--helper.c to
builtin/submodule.c one by one. Make necessary changes in the flag
parsing.
  - Once all the functions have been successfully copied, make the
default value of submodule.useBuiltin to true.
  - …eventually remove submodule--helper.c and the shell script
entirely, and deprecate the ‘submodule.useBuiltin’ option.

I wonder though how in the tests you are going to check both the new
builtin submodule and the old git-submodule.sh? Do you plan to run the
tests twice (once with submodule.useBuiltin set to true, and once with
it set to false)?

Re: [GSoC] My Git Dev Blog – Week 11

[Atharva Raykar]

Christian Couder <christian.couder@gmail.com> writes:

> On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar 
> <raykar.ath@gmail.com> wrote:
>
>> Here it is:
>> https://atharvaraykar.me/gitnotes/week11
>
> Great, thanks!
>
>> > Preview:
>> >
>> > - Project progress: where I discuss a rough plan for making 
>> > ’git
>> > submodule’ a
>> >   true builtin.
>
> So your plan is the following:
>
>   - Rename git-submodule.sh to git-submodule-legacy.sh.
>   - Create builtin/submodule.c, that will read from a config 
>   switch
> called ‘submodule.useBuiltin’. If this is set to false, just 
> call the
> legacy shell script, else use the builtin versions.
>   - Copy the functions from builtin/submodule--helper.c to
> builtin/submodule.c one by one. Make necessary changes in the 
> flag
> parsing.
>   - Once all the functions have been successfully copied, make 
>   the
> default value of submodule.useBuiltin to true.
>   - …eventually remove submodule--helper.c and the shell script
> entirely, and deprecate the ‘submodule.useBuiltin’ option.
>
> I wonder though how in the tests you are going to check both the 
> new
> builtin submodule and the old git-submodule.sh? Do you plan to 
> run the
> tests twice (once with submodule.useBuiltin set to true, and 
> once with
> it set to false)?

Yeah, that is what I thought of doing--first test only the 
component
that was ported with the configuration set to true, and then test 
the
whole thing with the configuration set to false. It does slightly
complicate things more than I'd like, but I cannot think of a 
better
way.

From what I could discern from the older threads and other similar
efforts, this was how it was done.

[GSoC] My Git Dev Blog – Week 11

[Atharva Raykar]

Hi all,

You can find the web version of this post here:
<https://atharvaraykar.me/gitnotes/week12>

Here's the contents of the post:


1 Week 12: Nearing the finish line
`================================'

1.1 Project Progress
`~~~~~~~~~~~~~~~~~~'

This week was more eventful than the last week. I sent a [patch] to finish the
conversion of whatever is left of submodule add. The response has been
favourable, and my first batch of conversions have already made their way to
master! While this is all fine, it would be nice if someone could give some
insight into [my question] on that series about the cache API. My use of the API
in the series seems to give correct results, but I don't understand what it's
actually doing, which is a not a good sign.

The [update conversion series] needs more eyes on it. Shourya Shukla has left some
helpful comments, but other than that I don't quite feel confident about the way
I structured the [run_update_command()] function. I wonder if I should hold on to
the follow-up of the update series until this one gets more comments, or if I
should just send the next series in the hopes of renewing interest in what's
already on the list. For now I am leaning on waiting a bit more.

I have also started some work on [making submodule a builtin]. That series is
still incomplete as of now, but should be in a reviewable state in a couple of
days.

With all of that it does feel like I am inching closer to the finish line with
my project. So is this stint with the Summer of Code. I don't think my work will
be merged before the Summer of Code ends, because it still needs a lot of
reviewing, but that's okay for me, since I plan to stick around for a bit even
after the program ends. That said, I'd appreciate more people volunteering for
reviews so we can wrap up the submodule conversion work faster :-)

It would be nice to see this work, which has spanned for [at least 6 years]
finally come to an end!


[patch] <https://lore.kernel.org/git/20210807071613.99610-1-raykar.ath@gmail.com>

[my question] <https://lore.kernel.org/git/20210805071917.29500-1-raykar.ath@gmail.com/>

[update conversion series] <https://lore.kernel.org/git/20210802130627.36170-1-raykar.ath@gmail.com/>

[run_update_command()] <https://github.com/tfidfwastaken/git/blob/6ce8fd2dc912f9073d6760b0aa77e0a5543ee26e/builtin/submodule--helper.c#L2340-L2436>

[making submodule a builtin] <https://github.com/tfidfwastaken/git/tree/submodule-make-builtin-2>

[at least 6 years] <https://github.com/git/git/commit/74703a1e4dfc5affcb8944e78b53f0817b492246>

1.1.1 Other Updates
------------------------------------------------------------------------

I will be busy from 15-19th August because of some family-related business,
which requires me to travel. It should not affect my work much, but I may be
slower to respond in that period.


---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

[GSoC] My Git Dev Blog – Week *12*

[Atharva Raykar]

Correction: This is week 12.

Re: [GSoC] My Git Dev Blog – Week 11

[Johannes Schindelin]

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

Hi,

On Mon, 2 Aug 2021, Atharva Raykar wrote:

>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar <raykar.ath@gmail.com> wrote:
> >
> > > Here it is:
> > > https://atharvaraykar.me/gitnotes/week11
> >
> > Great, thanks!
> >
> > > > Preview:
> > > >
> > > > - Project progress: where I discuss a rough plan for making ’git
> > > > submodule’ a
> > > >   true builtin.
> >
> > So your plan is the following:
> >
> >   - Rename git-submodule.sh to git-submodule-legacy.sh.
> >   - Create builtin/submodule.c, that will read from a config switch
> > called ‘submodule.useBuiltin’. If this is set to false, just call the
> > legacy shell script, else use the builtin versions.
> >   - Copy the functions from builtin/submodule--helper.c to
> > builtin/submodule.c one by one. Make necessary changes in the flag
> > parsing.
> >   - Once all the functions have been successfully copied, make the
> > default value of submodule.useBuiltin to true.
> >   - …eventually remove submodule--helper.c and the shell script
> > entirely, and deprecate the ‘submodule.useBuiltin’ option.
> >
> > I wonder though how in the tests you are going to check both the new
> > builtin submodule and the old git-submodule.sh? Do you plan to run the
> > tests twice (once with submodule.useBuiltin set to true, and once with
> > it set to false)?
>
> Yeah, that is what I thought of doing--first test only the component
> that was ported with the configuration set to true, and then test the
> whole thing with the configuration set to false. It does slightly
> complicate things more than I'd like, but I cannot think of a better
> way.
>
> From what I could discern from the older threads and other similar
> efforts, this was how it was done.

You can use the `linux-gcc` job for that, imitating how b2627cc3d4b (ci:
include the built-in `git add -i` in the `linux-gcc` job, 2020-01-14) did
it for the built-in `git add --interactive`:

    ci: include the built-in `git add -i` in the `linux-gcc` job

    This job runs the test suite twice, once in regular mode, and once
    with a whole slew of `GIT_TEST_*` variables set.

    Now that the built-in version of `git add --interactive` is
    feature-complete, let's also throw `GIT_TEST_ADD_I_USE_BUILTIN` into
    that fray.

    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index ff0ef7f08e7..4df54c4efea 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -20,6 +20,7 @@ linux-gcc)
        export GIT_TEST_OE_DELTA_SIZE=5
        export GIT_TEST_COMMIT_GRAPH=1
        export GIT_TEST_MULTI_PACK_INDEX=1
+       export GIT_TEST_ADD_I_USE_BUILTIN=1
        make test
        ;;
 linux-gcc-4.8)

Ciao,
Dscho

Re: [GSoC] My Git Dev Blog – Week 11

[Atharva Raykar]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Mon, 2 Aug 2021, Atharva Raykar wrote:
>
>> [...]
>
> You can use the `linux-gcc` job for that, imitating how b2627cc3d4b (ci:
> include the built-in `git add -i` in the `linux-gcc` job, 2020-01-14) did
> it for the built-in `git add --interactive`:
>
>     ci: include the built-in `git add -i` in the `linux-gcc` job
>
>     This job runs the test suite twice, once in regular mode, and once
>     with a whole slew of `GIT_TEST_*` variables set.
>
>     Now that the built-in version of `git add --interactive` is
>     feature-complete, let's also throw `GIT_TEST_ADD_I_USE_BUILTIN` into
>     that fray.
>
>     Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
> index ff0ef7f08e7..4df54c4efea 100755
> --- a/ci/run-build-and-tests.sh
> +++ b/ci/run-build-and-tests.sh
> @@ -20,6 +20,7 @@ linux-gcc)
>         export GIT_TEST_OE_DELTA_SIZE=5
>         export GIT_TEST_COMMIT_GRAPH=1
>         export GIT_TEST_MULTI_PACK_INDEX=1
> +       export GIT_TEST_ADD_I_USE_BUILTIN=1
>         make test
>         ;;
>  linux-gcc-4.8)

Thanks, this is helpful!