mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Atharva Raykar <>
Cc: git <>,
	Shourya Shukla <>,
	Shourya Shukla <>
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: <> (raw)
In-Reply-To: <>

On Thu, Apr 8, 2021 at 12:19 PM Atharva Raykar <> 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:
>     <>
>   - [Git Education] Conducted a workshop with attendance of hundreds of
>     students new to git, and increased the prevalence of of git's usage

s/of of git/of Git/

>     in my campus.
>     Photos: <> and
>     <>


> 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 `' 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

                       if (sanitize_submodule_env; cd "$sm_path" &&
$command "$sha1")
                               say "$say_msg"
                       elif test -n "$must_die_on_failure"
                               die_with_status 2 "$die_msg"


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 `'). 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]
>   <>

  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] Finish converting git submodule to builtin 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:

  List information:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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