From: Philip Oakley <philipoakley@iee.email>
To: Junio C Hamano <gitster@pobox.com>, Elia Pinto <gitter.spiros@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 01/23] contrib/coccinnelle: add equals-null.cocci
Date: Mon, 2 May 2022 11:00:48 +0100 [thread overview]
Message-ID: <13dc6ee6-f4ee-c246-b610-ec3d0a72a4ed@iee.email> (raw)
In-Reply-To: <xmqqmtg01mir.fsf@gitster.g>
On 02/05/2022 07:22, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> To avoid unnecessary conflicts with in-flight topics, ideally, we
>> perhaps could do something along this line:
>>
>> * Pick a recent stable point that is an ancestor of all topics in
>> flight. Add the new coccinelle rule file, take "make coccicheck"
>> output and create a two-patch series like Philip suggested. Queue
>> the result in a topic branch B.
>>
>> * For each topic in flight T, make a trial merge of T into B, and
>> examine "make coccicheck" output. Any new breakages such a test
>> finds are new violations the topic T introduces. Discard the
>> result of the trial merge, and add one commit to topic T that
>> corrects the violations the topic introduced, and send that fixup
>> to the author of the topic for consideration when the topic is
>> rerolled (or if the topic is in 'next', acked to be queued on
>> top). Do not fix the violations that is corrected when branch B
>> was prepared above.
>>
>> As I assumed that applying the patches in this series would create
>> the branch B, and then I saw that the tip of 'seen' after merging
>> this topic still needed to have a lot more fixes according to "make
>> coccicheck", I got a (false) impression that there are too many new
>> violations from topics in flight, which was the primary source of my
>> negative reaction against potential code churn. If we try the above
>> exercise, perhaps there may not be too many topics that need fix-up
>> beyond what we fix in the branch B, and if that is the case, I would
>> not be so negative.
> So I tried that myself, and the topic branch B was fairly
> straightforward to create.
>
> We have ~60 topics in flight (not counting this one), and it turns
> out that there is no topic that introduces new code that fails the
> equals-null.cocci rule. IOW, the follow-up fixup per topic turns
> out to be an empty set.
>
> So, I'd probably use the [01/23] and then a single ~5k lines patch
> that was generated with equals-null.cocci rule as the branch B
> above, let it percolate down from 'seen' to 'next' to eventually
> 'master'.
>
> Thanks.
That sounds like a good result.
It may also be worth Elia cross checking against a previous release
(v2.35.0?) for relatively recent introductions, to cover the potential
revert scenario, just in case..
Philip
next prev parent reply other threads:[~2022-05-02 10:01 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-30 4:13 [PATCH 00/23] add a new coccinelle semantic patch to enforce a Elia Pinto
2022-04-30 4:13 ` [PATCH 01/23] contrib/coccinnelle: add equals-null.cocci Elia Pinto
2022-04-30 19:34 ` Philip Oakley
2022-04-30 20:56 ` Junio C Hamano
2022-04-30 21:38 ` Philip Oakley
2022-04-30 23:13 ` Junio C Hamano
2022-05-01 0:20 ` Junio C Hamano
2022-05-01 17:04 ` Elia Pinto
2022-05-01 17:22 ` Philip Oakley
2022-05-01 23:14 ` Junio C Hamano
2022-05-01 23:37 ` Elia Pinto
2022-05-02 6:22 ` Junio C Hamano
2022-05-02 10:00 ` Philip Oakley [this message]
2022-05-02 16:32 ` Junio C Hamano
2022-05-02 11:07 ` Carlo Marcelo Arenas Belón
2022-04-30 4:13 ` [PATCH 02/23] apply.c: Fix coding style Elia Pinto
2022-04-30 4:13 ` [PATCH 03/23] archive.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 04/23] blame.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 05/23] branch.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 06/23] builtin/bisect--helper.c: " Elia Pinto
2022-05-03 9:54 ` Christian Couder
2022-04-30 4:13 ` [PATCH 07/23] builtin/checkout.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 08/23] builtin/clone.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 09/23] builtin/commit.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 10/23] builtin/diff.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 11/23] builtin/gc.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 12/23] builtin/index-pack.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 13/23] builtin/log.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 14/23] builtin/ls-remote.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 15/23] builtin/mailsplit.c: " Elia Pinto
2022-04-30 4:13 ` [PATCH 16/23] builtin/pack-redundant.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 17/23] builtin/receive-pack.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 18/23] builtin/replace.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 19/23] builtin/rev-parse.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 20/23] builtin/shortlog.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 21/23] builtin/tag.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 22/23] combine-diff.c: " Elia Pinto
2022-04-30 4:14 ` [PATCH 23/23] commit-graph.c: " Elia Pinto
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=13dc6ee6-f4ee-c246-b610-ec3d0a72a4ed@iee.email \
--to=philipoakley@iee.email \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gitter.spiros@gmail.com \
/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).