git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Philip Oakley <philipoakley@iee.email>
Cc: Elia Pinto <gitter.spiros@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 01/23] contrib/coccinnelle: add equals-null.cocci
Date: Sat, 30 Apr 2022 16:13:56 -0700	[thread overview]
Message-ID: <xmqqr15e5fm3.fsf@gitster.g> (raw)
In-Reply-To: <a3e06290-052e-af36-4170-301e567d561d@iee.email> (Philip Oakley's message of "Sat, 30 Apr 2022 22:38:52 +0100")

Philip Oakley <philipoakley@iee.email> writes:

> I think it goes both ways when the 'bad' style can be cargo-cult copied
> too easily, negating the value of the guidance.

Yes, and the cocci rules by themselves do not help protecting our
codebase against it all that much.

In order to help developers follow the guideline to avoid adding
_new_ instances (by copying-and-pasting), it should be easy to use
such a checker in such a way that we can notice only _new_ breakges
while ignoring existing offenders.  I do not think the current cocci
check target in our Makefile is prepared for that.

And there are two ways to deal with that shortcoming.

One, which often appears easier to implement but in the medium term
is very costly, is to freeze the codebase and apply tree-wide code
churn to make warning disappear.

Then _any_ breakages noticed by an inadequate tool, which does not
allow us to notice only the new breakages, after applying a patch to
such a cleansed codebase by definition are coming from the patch.

But it is costly.  The codebase is rarely frozen, so there isn't a
good time to apply such a patch, whether it is 22-patch series or a
single patch that concatenates everything into one.  There may be
more urgent issues than style fixes that would force us to revert a
change made before such a tree-wide clean-up, and when that happens,
such a "clean-up for clean-up's sake because we cannot check
incrementally" will inevitably conflict with such a change.

The other approach is to make it possible (and easy) to check
incrementally, so that we can detect new instances made by copying
and pasting.

Thanks.





  reply	other threads:[~2022-04-30 23:14 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 [this message]
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
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=xmqqr15e5fm3.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 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).