From: Atharva Raykar <raykar.ath@gmail.com>
To: Christian Couder <christian.couder@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: Sun, 11 Apr 2021 15:10:10 +0530 [thread overview]
Message-ID: <F6B9AC67-EB44-4FD9-A7A0-A6494BAE3BC7@gmail.com> (raw)
In-Reply-To: <CAP8UFD2hhtpnz+WE2J9iLbzfRJ2k5EOtUMRW=QcH9xe1U6y69g@mail.gmail.com>
> On 10-Apr-2021, at 18:29, Christian Couder <christian.couder@gmail.com> wrote:
>
> 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/
>
Thanks, will fix these.
>> 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.
It is a function that I intend to write, will make that more clear.
>> 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?
I could add more detail about the exact arguments each converted part
would take, but I feel a little hesitant because I will most likely
change my mind on a lot of those kind of lower-level decisions as I
understand the codebase better. The point I was trying to convey is
that the high-level workflow I would follow while converting would look
like this:
1. Identify parts in git-submodule.sh that have cohesive functionality
2. Rewrite that functionality in C, which can be invoked from
`git submodule--helper <function name> <args>`
3. Remove the shell code and replace it with the above invocation
4. Once the shell code is reduced to only a bunch of calls to
submodule--helper, wrap all of that into one call that looks like
`git submodule--helper update <flags>` that encapsulates all the
functionality done by the other helper function calls.
(In other words: I will cluster the functionality in a bottom-up way.
Maybe I should mention the above four points in my proposal?)
The example I gave for how to handle the presence of the remote flag
and the function that performs the module updation method (ie, the `case`
on line 611) was just to illustrate the above workflow, rather than say
that this is how I will exactly do it.
I also would like to know what level of granularity is ideal for the
proposal. For now I have tried to keep it at "whatever I will surely
follow through when I work on the project", which at the moment is the
covered by the four points I mentioned above.
If I go too much into detail about the functions and arguments
of every helper in my example, I will feel compelled to do the same for
the `git submodule add` example. I also will have to reason more carefully
because I do not want to end up in a situation where I do not actually
stick to my proposal all that much, because I realise in my investigation
phase that there is a different, much better way.
Do let me know what is preferred.
>> 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-11 9:40 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
2021-04-11 9:40 ` Atharva Raykar [this message]
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=F6B9AC67-EB44-4FD9-A7A0-A6494BAE3BC7@gmail.com \
--to=raykar.ath@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=periperidip@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).