Re: [PATCHv9 3/6] fetching submodules: respect `submodule.fetchJobs` config option

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2016, 01:12 UTC
Message-ID: <xmqqy4atz7u0.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kazD22FLv19CvmG+-dzGEP-uwr=fC_1VXB=sdzPBU_uww@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 14 quoted lines

>>         int git_config_nonnegative_int(const char *name, const char *value)
>>         {
>>                 int ret;
>>                 if (!git_parse_nonnegative_int(value, &ret))
>>                         die_bad_number(name, value);
>>                 return ret;
>>         }
>>
>> allowing
>>
>>                 parallel_jobs = git_config_nonnegative_int(var, val);
>>                 return 0;
>
> And I thought we wanted to prevent inventing yet another helper?

I actually do not think we mind git_parse_int(), git_parse_long(), and git_parse_uint() to complement git_parse_ulong(). I am not enthused by the "nonnegative-int" thing, though.

Do we have enough cases where we want to use signed type and reserve negative value for our own internal use (e.g. "unspecified yet")? If not, a very generic git_config_int() with a caller specific range check wouldn't look _so_ bad.

	parallel_jobs = git_config_int(var, val);
        if (parallel_jobs < 0)
	     	some corrective action;
	return 0;