My Git Dev Blog – Week 11

GSoC Atharva Raykar 3 participants 6 messages Aug 1, 2021 – Aug 17, 2021

lore

Share & tools

lore

Atharva Raykar

author

2021-08-01 13:51 UTC #0 lore raw

(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/[email protected]/>
[2] <https://atharvaraykar.me/gitnotes/week10#the-mailing-list-developer-workflow>

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

Atharva Raykar

author

2021-08-01 14:00 UTC #1 lore raw

Welp. I forgot the actual link to the blog.

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

Quoted 27 lines · 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/[email protected]/>
[2] <https://atharvaraykar.me/gitnotes/week10#the-mailing-list-developer-workflow>
Have a great week!
---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

Christian Couder

2021-08-02 06:52 UTC #2 lore raw

Quoted 2 lines · Atharva Raykar

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

Great, thanks!

Quoted 5 lines

Quoted 5 lines
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)?

Atharva Raykar

author

2021-08-02 12:44 UTC #3 lore raw

Quoted 30 lines · Christian Couder

Quoted 2 lines · Atharva Raykar
Here it is:
https://atharvaraykar.me/gitnotes/week11
Great, thanks!
Quoted 6 lines
Quoted 6 lines
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.

Quoted 4 lines

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.

Johannes Schindelin

2021-08-16 13:03 UTC #4 lore raw

Hi,

Quoted 35 lines · Atharva Raykar

Quoted 27 lines · Christian Couder
Quoted 2 lines · Atharva Raykar
Here it is:
https://atharvaraykar.me/gitnotes/week11
Great, thanks!
Quoted 5 lines
Quoted 5 lines
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.
Quoted 4 lines
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)?

Quoted 8 lines

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 <[email protected]>

Signed-off-by Junio C Hamano <[email protected]>

ci/run-build-and-tests.sh +1 -0

index ff0ef7f08e7..4df54c4efea 100755
@@ -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

Atharva Raykar

author

2021-08-17 05:01 UTC #5 lore raw

Quoted 27 lines · Johannes Schindelin

Hi,
Quoted 1 line · Atharva Raykar
[...]
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 <[email protected]>
Signed-off-by Junio C Hamano <[email protected]>
ci/run-build-and-tests.sh +0 -0
index ff0ef7f08e7..4df54c4efea 100755

ci/run-build-and-tests.sh linux-gcc) · line 26

Quoted 7 lines

ci/run-build-and-tests.sh +1 -0

@@ -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!