Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxx> > > 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.
