All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elia Pinto <gitter.spiros@gmail.com>
Cc: git@vger.kernel.org, Philip Oakley <philipoakley@iee.email>
Subject: Re: [PATCH 01/23] contrib/coccinnelle: add equals-null.cocci
Date: Sun, 01 May 2022 23:22:52 -0700	[thread overview]
Message-ID: <xmqqmtg01mir.fsf@gitster.g> (raw)
In-Reply-To: xmqqbkwg4zi7.fsf@gitster.g

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.

  parent reply	other threads:[~2022-05-02  6:23 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 [this message]
2022-05-02 10:00                   ` Philip Oakley
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=xmqqmtg01mir.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitter.spiros@gmail.com \
    --cc=philipoakley@iee.email \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.