Re: [PATCH v2 1/2] builtin/sparse-checkout: remove NEED_WORK_TREE flag

[Junio C Hamano <gitster@pobox.com>]

SZEDER Gábor <szeder.dev@gmail.com> writes:

>>                 struct option builtin_sparse_checkout_options[] = {
>>                         OPT_SUBCOMMAND("list", &fn, sparse_checkout_list),
>>                         OPT_SUBCOMMAND("init", &fn, sparse_checkout_init),
>>                         OPT_SUBCOMMAND("set", &fn, sparse_checkout_set),
>>                         OPT_SUBCOMMAND("add", &fn, sparse_checkout_add),
>>                         OPT_SUBCOMMAND("reapply", &fn, sparse_checkout_reapply),
>>                         OPT_SUBCOMMAND("disable", &fn, sparse_checkout_disable),
>>                         OPT_END(),
>>                 };
>> 
>> yet we have to sprinkle setup_work_tree() to all of these functions'
>> implementation.  If we were able to describe which selected ones do
>> not need the setup call, we could let the parse-options API to look
>> up the function and then before calling "fn" we could make the setup
>> call.  That would allow us to maintain the subcommands much nicely.
>
> It's easy enough to do in this particular case: there is an
> OPT_SUBCOMMAND_F() variant which takes an additional flags parameter,
> so we could add a PARSE_OPT_SETUP_WORK_TREE flag, check it in e.g.
> parse_subcommand(), and act accordingly if it's set.
>
> However, this wouldn't work when the command has a default operation
> mode and is invoked without any subcommands.  And I'm not sure about
> doing this in parse-options, because it's about, well, parsing
> options, not about doing fancy setup stuff.

Yes, exactly.  What I was imagining was more along the lines of

	parse_opt_subcommand_fn *fn = NULL;
	parse_opt_subcommand_fn *fn_with_setup = NULL;
	options[] = {
		OPT_SUBCOMMAND("list", &fn_with_setup, sparse_checkout_list),
		...
		OPT_SUBCOMMAND("check-rules", &fn, sparse_check_rules),
	};

	parse_options(...);

        if (fn_with_setup) {
		setup_worktree();
		fn = fn_with_setup;
	}
	fn(...);

But of course as a "safety" measure, one options[] array can all
point at the same "fn" variable or parse_options() becomes unhappy,
so the above does not work out of the box.