From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: ab/env-array
Date: Thu, 19 May 2022 14:41:12 -0700 [thread overview]
Message-ID: <xmqqzgjdkxon.fsf@gitster.g> (raw)
In-Reply-To: <220519.86sfp52u91.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Thu, 19 May 2022 21:28:58 +0200")
Æ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.
next prev parent reply other threads:[~2022-05-19 21:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 5:37 What's cooking in git.git (May 2022, #05; Mon, 16) Junio C Hamano
2022-05-17 13:10 ` Derrick Stolee
2022-05-20 23:28 ` Taylor Blau
2022-05-19 15:23 ` Carlo Marcelo Arenas Belón
2022-05-19 17:29 ` Junio C Hamano
2022-05-19 19:28 ` ab/env-array (was: What's cooking in git.git (May 2022, #05; Mon, 16)) Ævar Arnfjörð Bjarmason
2022-05-19 21:41 ` Junio C Hamano [this message]
2022-05-20 8:33 ` ab/env-array Ævar Arnfjörð Bjarmason
2022-05-19 19:34 ` ar/send-email-confirm-by-default (was: What's cooking in git.git (May 2022, #05; Mon, 16)) Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzgjdkxon.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).