Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> diff --git a/run-command.c b/run-command.c
>> index a8501e38ceb..324e9548469 100644
>> --- a/run-command.c
>> +++ b/run-command.c
>> @@ -1471,6 +1471,7 @@ enum child_state {
>> GIT_CP_WAIT_CLEANUP,
>> };
>>
>> +int run_processes_parallel_ungroup;
>
> This global variable seems to exist solely to avoid extending the
> signature of `run_processes_parallel_tr2()`. Let's not do that.
It may make the change even noisier, though.
>> @@ -1537,7 +1539,7 @@ static void pp_init(struct parallel_processes *pp,
>> get_next_task_fn get_next_task,
>> start_failure_fn start_failure,
>> task_finished_fn task_finished,
>> - void *data)
>> + void *data, const int ungroup)
>> {
>> int i;
Marking incoming parameter as const is probably a misfeature in C,
but doing so with file-scope static would not hurt too much, so if
this series needs no further reroll, I'd let it pass.
>> for (i = 0; i < n; i++) {
>> strbuf_init(&pp->children[i].err, 0);
>> child_process_init(&pp->children[i].process);
>> + if (!pp->pfd)
>
> It would be more logical to test for `pp->ungroup` than for `!pp->pfd`.
> In other instances below, the patch uses `if (ungroup)` instead. Let's not
> flip-flop between those two conditions, but the latter consistently.
I'd be somewhat sympathetic to the aversion to "flip-flop", but I
strongly disagree with you here.
"ungroup" does not have to stay to be the only reason why we do not
allocate the pp->pfd[] array, and what we care here is "if we are
polling for events, then do this initialization to the array", not
"if ungroup -> we must not have the pfd[] array -> so let's skip
it". We do not have to add more code that depends on that two step
inference when we do not need to.
>> @@ -1606,6 +1614,7 @@ static void pp_cleanup(struct parallel_processes *pp)
>> */
>> static int pp_start_one(struct parallel_processes *pp)
>> {
>> + const int ungroup = pp->ungroup;
>
> It costs readers a couple of moments when they stumble over code that is
> inconsistent with the existing code. In this instance, I find very little
> value in the `const` qualifier. Actually, this entire line is probably not
> worth having because `pp->ungroup` is just 4 characters longer than
> `ungroup`.
>
> This same comment applies to another hunk below, too.
>
> Things like this do take focus away from reviewing the interesting part of
> the contribution, which in particular in the case of a regression fix that
> many are waiting for is something to avoid.
OK.
Thanks.
