git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Collin Funk <collin.funk1@gmail.com>
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 22:56:06 +0000	[thread overview]
Message-ID: <aFSVhpnNnj6p3r7n@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <87msa3quzs.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On 2025-06-19 at 21:31:03, Collin Funk wrote:
> 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.

Yeah, then in that case, we probably want to ship some sort of container
and script that can do that.  Our default Rust target is Debian stable,
so that seems like a decent target if we need to pick a distro.  It's
also a very common distro used in containers, so it's widely available
to contributors using container-based development environments.

I still think that if we're going to have this functionality and expect
it to be used, we need to make it the default, build appropriate
tooling, and check it in CI.  If it's not fire-and-forget, people won't
use it.

> 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.

Certainly there are a lot of Vim and Emacs users in this project, but
there are also many people who are not.  I use Neovim myself and still
have to deal with wrapping lines at 80 characters.

I also don't think Vim actually honours per-directory configuration like
`.dir-locals.el` by default without turning on the `exrc` option, which
is rightly documented as a security risk.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2025-06-19 22:56 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
2025-06-19 22:56     ` brian m. carlson [this message]
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=aFSVhpnNnj6p3r7n@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=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 \
    /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).