git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Atharva Raykar <raykar.ath@gmail.com>
Cc: git <git@vger.kernel.org>,
	Shourya Shukla <shouryashukla.oo@gmail.com>,
	Shourya Shukla <periperidip@gmail.com>
Subject: Re: [GSoC][Draft Proposal v2] Finish converting git submodule to builtin
Date: Sat, 10 Apr 2021 14:59:59 +0200	[thread overview]
Message-ID: <CAP8UFD2hhtpnz+WE2J9iLbzfRJ2k5EOtUMRW=QcH9xe1U6y69g@mail.gmail.com> (raw)
In-Reply-To: <F3446051-620F-4C7B-A306-5C36922A976C@gmail.com>

On Thu, Apr 8, 2021 at 12:19 PM Atharva Raykar <raykar.ath@gmail.com> wrote:
>
> Here's my updated draft. Changes since v1:
>
> - Elaborated more on example porting strategy, stating how the patches
>    could be broken up.
> - Made language at the end of section 6 less ambiguous.
> - Updated status of microproject.
> - s/git/Git in several places.

Thanks for this summary of the changes since the previous version!

> 3 Me and Git
> ============
>
>   Here are the various forms of contributions that I have made to Git:
>
>   - [Microproject] userdiff: userdiff: add support for Scheme Status: In

s/userdiff: userdiff/userdiff/

>     progress, patch v3 requiring a review List:
>     <https://lore.kernel.org/git/20210408091442.22740-1-raykar.ath@gmail.com/>
>
>   - [Git Education] Conducted a workshop with attendance of hundreds of
>     students new to git, and increased the prevalence of of git's usage

s/git/Git/
s/of of git/of Git/

>     in my campus.
>     Photos: <https://photos.app.goo.gl/T7CPk1zkHdK7mx6v7> and
>     <https://photos.app.goo.gl/bzTgdHMttxDen6z9A>

[...]

> 6 General implementation strategy
> =================================
>
>   The way to port the shell to C code for `submodule' will largely
>   remain the same. There already exists the builtin
>   `submodule--helper.c' which contains most of the previous commands'
>   ports. All that the shell script for `git-submodule.sh' is doing for
>   the previously completed ports is parsing the flags and then calling
>   the helper, which does all the business logic.
>
>   So I will be moving out all the business logic that the shell script
>   is performing to `submodule--helper.c'. Any reusable functionality
>   that is introduced during the port will be added to `submodule.c' in
>   the top level.
>
>       For example: The general strategy for converting `cmd_update()' would
>       be to have a call to `submodule--helper' in the shell script to a
>       function which would resemble something like `module_update()'.

Does module_update() already exists? It's hard to understand if you
are referring to something that already exists (where?) or that you
would create (how?) here. More details about this would be nice.

> This
>       would perform the work being done by the shell script past the flags
>       being parsed and make the necessary call to `update_clone()', which
>       returns information about the cloned modules.

How does it return information?

> For each cloned module,
>       it will find out the update mode through `module_update_mode()', and
>       run the appropriate operation according to that mode (like a rebase,
>       if that was the update mode).
>
>       One possible way this work can be broken up into multiple patches, is
>       by moving over the shell code into C in a bottom-up manner.
>       For example: The shell part which retrieves the latest revision in the
>       remote (if --remote is specified) can be wrapped into a command of
>       `submodule--helper.c'.

Could you give an example of how the command would be named, what
arguments it would take and how it could be used?

> Then we can move the part where we run the
>       update method (ie the `case' on line 611 onwards) into a C function.

Do you mean the code that does something like:

                       case "$update_module" in
                       checkout)
                               ...
                       rebase)
                               ...
                       merge)
                               ...
                       !*)
                               ...
                       *)
                               ...
                       esac

                       if (sanitize_submodule_env; cd "$sm_path" &&
$command "$sha1")
                       then
                               say "$say_msg"
                       elif test -n "$must_die_on_failure"
                       then
                               die_with_status 2 "$die_msg"
                       else
                               err="${err};$die_msg"
                               continue
                       fi

?

Could you also give an example of how the command would be named, what
arguments it would take and how it could be used?

>       Eventually, the shell part will just look like a bunch of invocations
>       to `submodule--helper', at which point, the whole thing can be
>       encapsulated in a single command called `git submodule--helper update'
>       (Bonus: Move the whole functionality to C, including the parsing of
>       flags, to work towards getting rid of `git-submodule.sh'). I believe
>       this is a fairly non-destructive and incremental way to work, and the
>       porting efforts by Stefan seem to follow this same kind of philosophy.
>       I will most likely end up tuning the size of these increments when I
>       get around to planning in my first phase of the project.
>
>   After this process, I will be adding the `add' and `update' command to
>   the commands array in `submodule--helper.c'. And since these two
>   functions are the last bit of functionality left to convert in
>   submodules, an extended goal can be to get rid of the shell script
>   altogether, and make the helper into the actual builtin [1].
>
>   [1]
>   <https://lore.kernel.org/git/nycvar.QRO.7.76.6.2011191327320.56@tvgsbejvaqbjf.bet/>

  reply	other threads:[~2021-04-10 13:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-03 14:08 [GSoC][Draft Proposal] " Atharva Raykar
2021-04-05 16:02 ` Christian Couder
2021-04-08 10:19 ` [GSoC][Draft Proposal v2] " Atharva Raykar
2021-04-10 12:59   ` Christian Couder [this message]
2021-04-11  9:40     ` Atharva Raykar
2021-04-11 19:32       ` Kaartic Sivaraam
2021-04-12  5:56         ` Atharva Raykar
2021-04-12 13:29           ` Christian Couder
2021-04-11 10:17   ` [GSoC][Draft Proposal v3] " Atharva Raykar
2021-05-14 16:00   ` [GSoC][Draft Proposal v2] " Atharva Raykar
2021-05-16 18:40     ` Kaartic Sivaraam

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAP8UFD2hhtpnz+WE2J9iLbzfRJ2k5EOtUMRW=QcH9xe1U6y69g@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=periperidip@gmail.com \
    --cc=raykar.ath@gmail.com \
    --cc=shouryashukla.oo@gmail.com \
    --subject='Re: [GSoC][Draft Proposal v2] Finish converting git submodule to builtin' \
    /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

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).