[GSoC] My Git Dev Blog – Week 11

(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
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

Welp. I forgot the actual link to the blog.

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

Atharva Raykar [off-list ref] 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
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar [off-list ref] wrote:

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

Great, thanks!

quoted

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

Christian Couder [off-list ref] writes:

On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar 
[off-list ref] wrote:

quoted

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

Great, thanks!

quoted

quoted

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.

Hi,

On Mon, 2 Aug 2021, Atharva Raykar wrote:

Christian Couder [off-list ref] writes:

quoted

On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar [off-list ref] wrote:

quoted

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

Great, thanks!

quoted

quoted

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 [off-list ref]
    Signed-off-by: Junio C Hamano [off-list ref]

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

Johannes Schindelin [off-list ref] writes:

Thanks, this is helpful!