qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	luoyonggang@gmail.com, qemu-level <qemu-devel@nongnu.org>
Subject: Re: How about using clang-format instead checkpatch for fixing style?
Date: Fri, 9 Oct 2020 14:38:40 +0100	[thread overview]
Message-ID: <20201009133840.GA25901@redhat.com> (raw)
In-Reply-To: <27f82fe6-5b0f-7e35-29d9-7b00ae8f189e@redhat.com>

On Fri, Oct 09, 2020 at 03:25:04PM +0200, Paolo Bonzini wrote:
> On 09/10/20 15:02, 罗勇刚(Yonggang Luo) wrote:
> > We can even using clang-format to format the whole repository.
> 
> checkpatch does other checks than formatting.
> 
> Reformatting the whole repository has been mentioned many times, people
> were worried of messing up the result of "git blame".  But without doing
> that, it's hard to get rid of checkpatch because checkpatch only looks
> at the lines that are touched by the patch.

It is a no-win situation.

checkpatch.pl is code that makes people run away screaming in horror,
because who really wants to look at Perl code that tries to parse C
code with regexes. The fact that you can submit a patch and get
complaints about things you didn't actually change is a poor experiance,
especially for new contributors who will wonder what they did wrong.

Certain subsystem maintainers have done bulk cleanups for pieces of
code before, most notably culling tabs. So we have taken the pain
a little before. I presume we'll continue to periodically clean
code.

Aside from the git blame pain, there will also be a period of time
when cherry-picking patches back to old versions will be tediously
conflicting, potentially forcing cherr-picking of the style cleanup
patches too. If the cleanup patches are fine grained it might not
be too terrible though.

So we have pain with current state and we have pain with use of
clang-format. The difference is the current pain is long term
ongoing pain, while the clang-format pain will be an initial
hit whose impact will slowly fade over time.

Personally I think it would be worth the change in the long
term. I should really put my money where my mouth is though and
propose it for libvirt too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  parent reply	other threads:[~2020-10-09 13:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 13:02 How about using clang-format instead checkpatch for fixing style? 罗勇刚(Yonggang Luo)
2020-10-09 13:25 ` Paolo Bonzini
2020-10-09 13:30   ` 罗勇刚(Yonggang Luo)
2020-10-09 13:38   ` Daniel P. Berrangé [this message]
2020-10-09 13:44     ` 罗勇刚(Yonggang Luo)
2020-10-09 13:48   ` 罗勇刚(Yonggang Luo)

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=20201009133840.GA25901@redhat.com \
    --to=berrange@redhat.com \
    --cc=luoyonggang@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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).