Re: [GSoC] My Git Dev Blog – Week 11
Hi,
On Mon, 2 Aug 2021, Atharva Raykar wrote:
Show 43 quoted lines
>
> 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
Atharva Raykar
