git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Collin Funk <collin.funk1@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Karthik Nayak" <karthik.188@gmail.com>,
	"Patrick Steinhardt" <ps@pks.im>, "René Scharfe" <l.s.r@web.de>
Subject: Re: .clang-format: how useful, how often used, and how well maintained?
Date: Thu, 19 Jun 2025 14:31:03 -0700	[thread overview]
Message-ID: <87msa3quzs.fsf@gmail.com> (raw)
In-Reply-To: <aFR-Yf0PMj30ex2O@fruit.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I agree most people probably do not use it, probably for the reasons I
> don't.  I don't know if clang-format produces stable output: that is,
> using a newer version of clang-format with the same config does not
> result in diff changes.  If it does, then we can simply pick a set of
> style configs and a minimum version and tell people to apply it.
>
> We can then check it in CI and if CI fails, we can output a
> base64-encoded diff (since it's going to have lots of whitespace, base64
> encoding will be practically useful) that the author can apply.  Then
> people using esoteric systems without clang-format can simply apply the
> diff from CI.
>
> If clang-format does not produce stable output, we're going to have a
> bunch of practical problems.  I use Debian unstable at home and I know
> Peff does as well, but I also use Ubuntu 24.04 at work.  Some
> contributors use Fedora or Cygwin, and we're all going to have a giant
> problem picking a consistent version of clang-format to use such that
> people don't have to compile their own or use external packages. Perhaps
> we can create a small script that does the tidying in a Linux
> Docker/Podman container in that case.

From what I remember, clang-format is not at all stable between
releases. Newer versions will produce different output than old 
ones (usually better, but that does not matter).

For the reasons that you already mention, it ends up being a chore, in
my opinion. I don't think we should expect everyone to build/install a
clang-format version that is newer or older than what their distro ships
with, just to align the output with the project.

If you wanted to be help avoid badly formatted patches adding a .vimrc
and .dir-locals.el file would cover most people, I think. For Emacs, the
.dir-locals.el would be something simple like:

    (c-mode . ((c-file-style . "linux")
               (fill-column . 80)
               ((indent-tabs-mode . t))))

At least with Emacs it is easy to type things that break these rules. So
one can avoid diffs like this, which clang-format would produce:

> -		/* Warn on any additional signatures, as they will be ignored. */
> +		/* Warn on any additional signatures, as they will be ignored.
> +		 */

I assume this is similar for vim, but I do not use it enough.

Collin

  reply	other threads:[~2025-06-19 21:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 16:38 .clang-format: how useful, how often used, and how well maintained? Junio C Hamano
2025-06-19 20:30 ` Christian Couder
2025-06-20  0:20   ` Junio C Hamano
2025-06-20 14:08     ` Christian Couder
2025-06-20 16:36       ` Junio C Hamano
2025-06-21  5:07       ` Jeff King
2025-06-22  4:11         ` Junio C Hamano
2025-06-19 21:17 ` brian m. carlson
2025-06-19 21:31   ` Collin Funk [this message]
2025-06-19 22:56     ` brian m. carlson
2025-06-20 15:19       ` Junio C Hamano
2025-07-01 14:08         ` Toon Claes
2025-07-01 16:59           ` Johannes Schindelin
2025-07-01 20:42           ` Junio C Hamano
2025-07-01 21:12             ` Junio C Hamano
2025-06-23  8:46 ` Karthik Nayak
2025-06-23 16:26   ` Junio C Hamano
2025-06-24 23:27     ` Karthik Nayak

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=87msa3quzs.fsf@gmail.com \
    --to=collin.funk1@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=l.s.r@web.de \
    --cc=ps@pks.im \
    --cc=sandals@crustytoothpaste.net \
    /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).