On Thu, Jun 4, 2020 at 9:17 AM Shourya Shukla <shouryashukla.oo@xxxxxxxxx> wrote: > > On 03/06 01:02, Junio C Hamano wrote: > > I'd expect that when that day with no scripted parts of "git > > submodule" remains comes, the main entry point functions in > > builtin/submodule--helper.c (like module_list(), update_clone(), > > module_set_branch(), etc.) will become helper functions that live in > > submodule-lib.c and would be called from builtin/submodule.c. And > > the conversion would rip out calls to parse_options() in each of > > these functions that would migrate to submodule-lib.c > > > > Side note: instead of adding submodule-lib.c, you could add them > > directly to submodule.c if they are small enough. I am however > > modeling after how the "diff" family was converted to C; the > > diff-lib.c layer is "library-ish helpers that get pre-parsed > > command line arguments and performs a single unit of work" that > > utilizes service routines at the lower layer that are in diff.c > > and submodule-lib.c and submodule.c will be in a similar kind of > > relationship. > > There does exist a `submodule.c` outside of `builtin/` which has various > helper functions. Will that require renaming to `submodule-lib.c`? No, as Junio says that "submodule-lib.c and submodule.c will be in a similar kind of relationship" as diff.c and diff-lib.c. > BTW > `set-branch` is a subcommand of `git submodule` so do we have to put it > into `submodule-lib.c` if there were to be one? > What is the motivation behind modelling it on the diff-family? Maybe to separate helper functions for submodules from other submodule functions.
