On Thu, May 19 2022, Junio C Hamano wrote: > Æ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. Makes sense, I re-rolled a v2 with the removal of the *.cocci rule added.
