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

From: Atharva Raykar <raykar.ath@gmail.com>
Date: Aug 2, 2021, 12:44 UTC
Message-ID: <m2pmuwrp7x.fsf@gmail.com>
In-Reply-To: <CAP8UFD0V3hoDUkeMyAaeo_=cZ46P-Yka1v67FFNbQ5Me5Hh_+g@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 40 quoted lines

> 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.