Re: [GSoC][PATCH v5] submodule: port subcommand 'set-branch' from shell to C

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 3, 2020, 20:02 UTC
Message-ID: <xmqqtuzrrk8r.fsf@gitster.c.googlers.com>
In-Reply-To: <20200603001225.GB2222@danh.dev>

Đoàn Trần Công Danh  <congdanhqx@gmail.com> writes:

Show 26 quoted lines

> On 2020-06-02 10:58:45-0700, Junio C Hamano <gitster@pobox.com> wrote:
>> Shourya Shukla <shouryashukla.oo@gmail.com> 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".