git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Atharva Raykar <raykar.ath@gmail.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git <git@vger.kernel.org>, Shourya Shukla <periperidip@gmail.com>,
	Philippe Blain <levraiphilippeblain@gmail.com>,
	Kaartic Sivaraam <kaartic.sivaraam@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [GSoC] My Git Dev Blog – Week 11
Date: Mon, 02 Aug 2021 18:14:02 +0530	[thread overview]
Message-ID: <m2pmuwrp7x.fsf@gmail.com> (raw)
In-Reply-To: <CAP8UFD0V3hoDUkeMyAaeo_=cZ46P-Yka1v67FFNbQ5Me5Hh_+g@mail.gmail.com>


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.

  reply	other threads:[~2021-08-02 12:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01 13:45 [GSoC] My Git Dev Blog – Week 11 Atharva Raykar
2021-08-01 14:00 ` Atharva Raykar
2021-08-02  6:52   ` Christian Couder
2021-08-02 12:44     ` Atharva Raykar [this message]
2021-08-16 13:02       ` Johannes Schindelin
2021-08-17  5:01         ` Atharva Raykar
  -- strict thread matches above, loose matches on Subject: below --
2021-08-08 13:43 Atharva Raykar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2pmuwrp7x.fsf@gmail.com \
    --to=raykar.ath@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=periperidip@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).