From: Johannes Schindelin <Johannes.Schindelin@gmx.de> To: "Ævar Arnfjörð Bjarmason" <email@example.com> Cc: Jonathan Tan <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v2 2/3] submodule: port submodule subcommand 'add' from shell to C Date: Thu, 19 Nov 2020 13:38:16 +0100 (CET) [thread overview] Message-ID: <nycvar.QRO.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2412 bytes --] Hi Ævar, On Thu, 19 Nov 2020, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Nov 19 2020, Jonathan Tan wrote: > > >> Whew. > >> > >> This was way too big to be reviewed in a single sitting. I do not > >> know offhand if there is a better way to structure the changes into > >> a more digestible pieces to help prevent reviewers from overlooking > >> potential mistakes, though. > >> > >> Thanks. > > > > I just took a look at this, and one thing that would have helped is if > > you ported the end of the function first in a commit, and work your way > > backwards (in one or more commits). > > > > After reading through the whole thing, I saw that this is mostly a > > straightforward start-to-finish port (besides factoring out code into > > functions), but it would be much easier for reviewers to conceptualize > > and discuss the different parts if they were already divided. > > Having done some minor changes to git-submodule.sh recently, I wondered > if we weren't at the point where it would be a nice approach to invert > the C/sh helper relationship. > > I.e. write git-submodule.c, which would be the small entry point, it > would then mostly dispatch to a submodule--helper, which would in turn > mostly dispatch to a new submodule--helper-sh (containing most of the > current git-submodule.sh code), which in turn would re-dispatch to the C > submodule--helper (which as an aside, then sometimes calls itself via > process invocation). > > It's quite a bit of spaghetti code, but means that there's a straighter > path to porting some of the setup code such as the "--check-writeable", > is_absolute_path() etc. being changed at the start of the change here to > git-submodule.sh. Looking at https://github.com/gitgitgadget/git/blob/ss/submodule-add-in-c/git-submodule.sh, I see that while there are still 794 lines, most of it is just mostly redundant option parsing. The only function left to convert is `cmd_update()`, and the first half was already converted to C long ago, via the `git submodule--helper update-clone` subcommand: https://github.com/gitgitgadget/git/blob/ss/submodule-add-in-c/git-submodule.sh#L269-L530 At this stage I suspect that having a little more patience would make more sense. After `cmd_update` is converted, we can simply finish the conversion, without having to keep the shell script around. Ciao, Dscho
next prev parent reply other threads:[~2020-11-19 12:38 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-07 7:45 [PATCH v2 0/3] submodule: port subcommand add " Shourya Shukla 2020-10-07 7:45 ` [PATCH v2 1/3] dir: change the scope of function 'directory_exists_in_index()' Shourya Shukla 2020-10-07 18:05 ` Junio C Hamano 2020-10-12 10:11 ` Shourya Shukla 2020-11-18 23:25 ` Emily Shaffer 2020-10-07 7:45 ` [PATCH v2 2/3] submodule: port submodule subcommand 'add' from shell to C Shourya Shukla 2020-10-07 18:37 ` Junio C Hamano 2020-10-07 22:19 ` Junio C Hamano 2020-10-08 17:19 ` Junio C Hamano 2020-10-09 5:09 ` Junio C Hamano 2020-11-18 23:13 ` Jonathan Tan 2020-11-19 7:44 ` Ævar Arnfjörð Bjarmason 2020-11-19 12:38 ` Johannes Schindelin [this message] 2020-11-19 20:37 ` Junio C Hamano 2020-10-07 7:45 ` [PATCH v2 3/3] t7400: add test to check 'submodule add' for tracked paths Shourya Shukla 2020-11-19 0:03 ` [PATCH v2 0/3] submodule: port subcommand add from shell to C Josh Steadmon
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=nycvar.QRO.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 2/3] submodule: port submodule subcommand '\''add'\'' from shell to C' \ /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
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).