Subject: Re: ab/env-array

From: Junio C Hamano <[email-masked]>
Date: Thu, 19 May 2022 14:41:12 -0700

Ævar Arnfjörð Bjarmason <[email-masked]> writes:

> On Mon, May 16 2022, Junio C Hamano wrote:
>
>> * ab/env-array (2022-04-06) 3 commits
>>  - run-command API users: use "env" not "env_array" in comments & names
>>  - run-command API: rename "env_array" to "env"
>>  - cocci: add a rename of "struct child_process"'s "env_array" to "env"
>>
>>  Rename .env_array member to .env in the child_process structure.
>>
>>  On hold.
>>  source: <[email-masked]>
>
> I'm not sure if the "on hold" status is wanted here, or a holdover from
> around the release time (per
> https://lore.kernel.org/git/?q=ab%2Fenv-array); but in this case I think
> it would be very nice if we could advance this sooner than later.
>
> I'm aware of a couple of topics that would semantically conflict with it
> if re-submitted (IIRC the rest of submodule-in-C is one). So if we're
> going to do the s/env_array/env/g at all it seems better to do it sooner
> than later.

I do not think the run_command.cocci should remain in the tree at
the end of this topic, as anybody who uses .env_array will be broken
at compile time, so the only effect it adds is to make it take more
time run "make coccicheck" for no good reason.  Anything it would
catch we can find with "make" a lot faster.  It may serve as a
dormant mine to surprise future developer who may want to add
.env_array member for other reasons, too ;-)

Instead of renaming .pending.cocci to .cocci I think the file should
be removed, no?

Other than that, I think this can go in any time, before or after
the topics that add more mention of the .env_array member that are
in-flight.  The rename done in this topic felt somewhat irritating
while merging them, but the conflicts have been manageable.