Junio C Hamano <gitster@xxxxxxxxx> writes:
> "Philippe Blain via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
>> From: Philippe Blain <levraiphilippeblain@xxxxxxxxx>
>>
>> Using a named enum allows casting an integer to the enum type in both
>> GDB and LLDB:
>>
>> (gdb) p (enum diff_submodule_format) options->submodule_format
>> $1 = DIFF_SUBMODULE_LOG
>
> Hmph, this was somewhat unexpected and quite disappointing.
>
> Because that's not what those "Let's move away from #define'd
> constants and use more enums" said when they sold their "enum" to
> us. In the diff_options struct, the .submodule_format member is of
> type enum already, so, if we trust what they told us when they sold
> their enums, "p options->submodule_format" should be enough to give
> us "DIFF_SUBMODULE_LOG", not "1", as its output. Do you really need
> the cast in the above example?
>
>> Name the enum listing the different RECURSE_SUBMODULES_* modes, to make
>> debugging easier.
>
> Even though this patch may be a good single step in the right
> direction, until it is _used_ to declare a variable or a member of a
> struct of that enum type, it probably is not useful as much as it
> could be. The user needs to know which enum is stored in that "int"
> variable or member the user is interested in to cast it to.
>
> That is, many changes like this one.
>
> diff --git i/builtin/pull.c w/builtin/pull.c
> index c8457619d8..f2fd4784df 100644
> --- i/builtin/pull.c
> +++ w/builtin/pull.c
> @@ -71,7 +71,7 @@ static const char * const pull_usage[] = {
> /* Shared options */
> static int opt_verbosity;
> static char *opt_progress;
> -static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
> +static enum submodule_recurse_mode recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
>
> /* Options passed to git-merge or git-rebase */
> static enum rebase_type opt_rebase = -1;
Your comment on the use of RECURSE_SUBMODULES_DEFAULT elsewhere [1]
reminded me of how odd this enum actually is.
* submodule_recurse_mode is used almost exclusively by fetch and push
because they are the only commands that accept anything other than
true/false.
* however, it is also used by
submodule.c:config_update_recurse_submodules to store true/false (it
don't even use RECURSE_SUBMODULES_DEFAULT!)
i.e. I suspect that the enum is only relevant for fetch/push, but its
values for _ON and _OFF have been co-opted for other things.
This patch and the suggestion of s/int/enum submodule_recurse_mode makes
sense, though I think we can take this a bit further in some follow-up
work:
If I am correct in my suspicion earlier, then submodule_recurse_mode can
be made even more specific, like "submodule_transport_mode", and all
non-transport related uses can be replaced with int.
If I am wrong and there are some legitimate uses for
submodule_recurse_mode that I have missed, it might still be worthwhile
to separate the different uses of the enum so that it doesn't end up
overloaded.
[1] https://lore.kernel.org/git/xmqqr19cjuzw.fsf@gitster.g
