Re: [PATCH] submodule.h: use a named enum for RECURSE_SUBMODULES_*

From: Glen Choo <chooglen@google.com>
Date: Jan 7, 2022, 17:43 UTC
Message-ID: <kl6lczl3786k.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <3160705c-d95c-c389-e929-f1f6bbcd80fc@gmail.com>

Philippe Blain <levraiphilippeblain@gmail.com> writes:

Show 20 quoted lines

>> 
>> 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;
>> 
>
> Yes, this is a parallel effort that could be done, I agree, but my patch
> was meant to help in the mean time.

There are quite a few sites that could use this s/int/enum submodule_recurse_mode change. I suppose one _could_ change all of them at once, but that seems cumbersome to review and prone to conflict.

So that this isn't debugger-only, I'd be happy with at least one change (perhaps the one that inspired you to name the enum in the first place), and making the other changes when it makes sense, e.g. I can do this for the fetch machinery while I work on enhancements to `fetch --recurse-submodules`.