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/>
next prev parent 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:
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 \
/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.
Code repositories for project(s) associated with this public 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).