From: Junio C Hamano <gitster@pobox•com>
To: Christian Couder <christian.couder@gmail•com>
Cc: 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: Fri, 20 Jun 2025 09:36:58 -0700 [thread overview]
Message-ID: <xmqqy0tm2wut.fsf@gitster.g> (raw)
In-Reply-To: <CAP8UFD27tQ3uhQW5zkPfFZSF=3FGEmi-rBYu3A_zZ8oNbUiNag@mail.gmail.com> (Christian Couder's message of "Fri, 20 Jun 2025 16:08:32 +0200")
Christian Couder <christian.couder@gmail•com> writes:
> It's up to each one to decide if they prefer post-commit or pre-commit
> hooks or other ways to trigger the style check. So yeah, we could both
> suggest using hooks and add a format-patch option to make it easier
> for those who don't want a hook.
The thing is, I have no idea what the "option" to format-patch you
talk about should look like. This topic is about improving Git
codebase by helping Git developers, and I do not want to add a
project-specific option to the tool that is meant for the general
public.
>> Or just write that command invocation into "MyFirstContribution" etc.?
>
> Yeah, we could do that too.
I think that is a good first step. Give an example that shows that
the tool can give suboptimal suggestions as well as good ones, to
stress the point that the output from the tool should not be taken
blindly, but should still be looked at.
>> What I called "once the code is written" is something I would refuse
>> to accept as a "style fix" patch, but they are still improvements
>> and it would be great if contributors followed these style checker's
>> suggestion _before_ sending the patch to the list.
>
> If we encourage a style checker to make suggestions that are often in
> bikeshedding territory, then I think we take the risks of:
I do not think I am advocating to encourage a style checker to make
bikeshedding suggestions at all. We are not discussing any change
to .clang-format file in this discussion (a side thread we discussed
about concluding a year-old experiment, which would result in a small
change to the file, though).
> - annoying some users who disagree with some suggestions,
That I do not think we care too much. This is not about "users".
> - having bikeshedding discussions on the list (like this one) about
> things that are just not worth it,
But now we have a good thing to point at. "You want to bikeshed?
Let's see what clang-format with our recommended setting says." And
the discussion should end there.
> - the style checker being actually wrong (because of the context for example).
If you are worried about "bikeshedding territory", there is no
additional risks for the tool to be actually wrong. Whether you
blindly take its stylistic changes or not, you'd need to be careful
about tool changing the meanings of the code it is touching.
> In my opinion the possible small gains are not worth taking those
> risks.
So, from my point of view, I am not sure if there is _any_ risks,
but again I do not know who you think is advocating for more
bikeshedding via the style checker.
> In other words from a style checker I'd rather have fewer
> suggestions that are more likely to be right, than more suggestions
> that are more likely to be dubious.
No question about that, but I see no logical linkage between what
you said above and this goal, sorry.
> I agree that in the example above the suggested change might be good.
> But if there is ...
Don't move the goalpost. It is not the case we are discussing.
> So my opinion is that a style checker that doesn't take into account
> the length of the lines around where it makes suggestions is likely to
> make a number of wrong line wrapping suggestions.
Your example is not even about "around", but the exact line that is
being changed, isn't it? Even if the line being changed were the
only overly long line, and all lines around it were below the length
that is comfortably read with minimal horizontal eye movement, we
still want to wrap it down, don't we?
next prev parent reply other threads:[~2025-06-20 16:37 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 [this message]
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
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=xmqqy0tm2wut.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=karthik.188@gmail$(echo .)com \
--cc=l.s.r@web$(echo .)de \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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