All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Christian Couder" <christian.couder@gmail.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: Sat, 21 Jun 2025 21:11:17 -0700	[thread overview]
Message-ID: <xmqqfrfs8lga.fsf@gitster.g> (raw)
In-Reply-To: <20250621050743.GA3007684@coredump.intra.peff.net> (Jeff King's message of "Sat, 21 Jun 2025 01:07:43 -0400")

Jeff King <peff@peff.net> writes:

> My ideal workflow would probably be taking a pass with:
>
>   git rebase -x 'git clang-format --style=file -p HEAD^ || git commit --no-edit --amend -a'
>
> is a better match.  That command is a bit of a mouthful, but we
> could perhaps roll it into a script or a Makefile target.

The "-p" option does sound like a good thing.  Taking the tool's
suggestion wholesale without human judgement would be better than
taking what a human developer typed as-is only for somebody totally
new to the language and to the project.  For more experienced
developers, I would trust human judgement a lot more than I trust
the tool's suggestion, and "-p" may be a good escape hatch.

> The current "make
> style" only looks at uncommitted changes in the working tree (and of
> course isn't interactive).

Yes, that makes it much less useful than it could be.

> The big pain I see in this (or any other workflow) is getting bugged
> about suggestions you've rejected. In an ideal world we'd tune
> .clang-format so that all of its suggestions are good, but I don't think
> we're there yet. ;)

Me neither.

  reply	other threads:[~2025-06-22  4:11 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 [this message]
2025-06-19 21:17 ` brian m. carlson
2025-06-19 21:31   ` Collin Funk
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=xmqqfrfs8lga.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --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 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.