Re: [PATCH 06/15] update submodules: add submodule config parsing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> Similar to b33a15b08 (push: add recurseSubmodules config option,
> 2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the
> fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code
> that is later used to parse whether we are interested in updating
> submodules.
>
> We need the `die_on_error` parameter to be able to call this parsing
> function for the config file as well, which if incorrect lets Git die.
>
> As we're just touching the header file, also mark all functions extern.
>
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
>  submodule-config.c | 22 ++++++++++++++++++++++
>  submodule-config.h | 17 +++++++++--------
>  2 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/submodule-config.c b/submodule-config.c
> index 93453909cf..93f01c4378 100644
> --- a/submodule-config.c
> +++ b/submodule-config.c
> @@ -234,6 +234,28 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg)
>         return parse_fetch_recurse(opt, arg, 1);
>  }
>
> +static int parse_update_recurse(const char *opt, const char *arg,
> +                               int die_on_error)
> +{
> +       switch (git_config_maybe_bool(opt, arg)) {
> +       case 1:
> +               return RECURSE_SUBMODULES_ON;
> +       case 0:
> +               return RECURSE_SUBMODULES_OFF;
> +       default:
> +               if (!strcmp(arg, "checkout"))
> +                       return RECURSE_SUBMODULES_ON;
> +               if (die_on_error)
> +                       die("bad %s argument: %s", opt, arg);
> +               return RECURSE_SUBMODULES_ERROR;
> +       }
> +}

Ok so this function here reads a recurse submodules parameter which is
a boolean or it can be set to the word "checkout"? Why does checkout
need its own value separate from true? Just so that we have a synonym?
or so that we can expand on it in the future?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]