Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> writes:
> On 2020-06-02 10:58:45-0700, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Shourya Shukla <shouryashukla.oo@xxxxxxxxx> writes:
>>
>> > + * though there is nothing to make less verbose in this subcommand.
>> > + */
>> > + struct option options[] = {
>> > + OPT_NOOP_NOARG('q', "quiet"),
>> > + OPT_BOOL('d', "default", &opt_default,
>> > + N_("set the default tracking branch to master")),
>> > + OPT_STRING('b', "branch", &opt_branch, N_("branch"),
>> > + N_("set the default tracking branch")),
>> > ...
>> > + OPT_END()
>> > + };
>> > + const char *const usage[] = {
>> > + N_("git submodule--helper set-branch [-q|--quiet] (-d|--default) <path>"),
>> > + N_("git submodule--helper set-branch [-q|--quiet] (-b|--branch) <branch> <path>"),
>>
>>
>> I notice that we gained back -d and -b shorthands that was
>> advertised but not implemented the previous rounds. It is a bit
>> curious that we are adding these short-hands that nobody uses,
>> though.
>
> I think a day will come, when all git-submodule functionalities will
> run by calling git-submodule--helper.
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.
> In that day, we will use current git-submodule--helper as the new
> git-submodule.
No, I do not think so. Most of the option parsers would be redone
in builtin/submodule.c; only some that can be used as-is may migrate
as a whole to builtin/submodule.c and its parse_options() stuff
reused, but most of what is in submodule--helper would have to lose
their parse_options() calls, as nobody would be using module_list()
when there is no scripted "git submodule" exists, for example.
> Or is that a complain for missing some tests?
No, it was "do the minimum necessary for an implementation detail,
as we'll discard that part later anyway".
