Re: ab/env-array

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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: <cover-0.3-00000000000-20220406T104134Z-avarab@gmail.com>
>>
>> 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.