Hi, On Mon, 2 Aug 2021, Atharva Raykar wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > On Sun, Aug 1, 2021 at 4:00 PM Atharva Raykar <raykar.ath@xxxxxxxxx> 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@xxxxxx> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> 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
