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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 16, 2021, 13:02 UTC
Message-ID: <nycvar.QRO.7.76.6.2108161500200.55@tvgsbejvaqbjf.bet>
In-Reply-To: <m2pmuwrp7x.fsf@gmail.com>

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