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.
