Re: [PATCH v3 6/9] hook: add -j/--jobs option to git hook run

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Mar 18, 2026, 19:00 UTC
Message-ID: <87v7et0xq9.fsf@collabora.com>
In-Reply-To: <xmqq7brcst9o.fsf@gitster.g>

On Sun, 15 Mar 2026, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>
>> diff --git a/hook.c b/hook.c
>> index 815b299bf8..299cbf9e97 100644
>> --- a/hook.c
>> +++ b/hook.c
>> @@ -567,15 +567,17 @@ static unsigned int get_hook_jobs(struct repository *r,
>>  	if (!options->stdout_to_stderr)
>>  		return 1;
>>  
>> -	/* An explicit job count (FORCE_SERIAL jobs=1, or -j from CLI). */
>> -	if (options->jobs)
>> -		return options->jobs;
>> +	/* Pinned serial: FORCE_SERIAL (internal) or explicit -j1 from CLI. */
>> +	if (options->jobs == 1)
>> +		return 1;
>
> Hmph, puzzled.  
>
> Shouldn't just -j1 but -j12 from CLI also trump configured
> parallelism?  Which was what the code before this step already did,
> no?

Yes. I think I was a bit unsure of the -jN priority when writing this, whether the -jN arg is stronger than for e.g. if the hook is marked as parallel = false. What to do in this case? :)

As you noted on the other patch, the user's intention is clear when passing -jN, so maybe we could bring back the old code and issue a warning, something like:

"hook X is not marked as parallel=true, running in parallel anyway due to the -jN flag".