Re: .clang-format: how useful, how often used, and how well maintained?

From: Jeff King <peff@peff.net>
Date: Jun 21, 2025, 05:07 UTC
Message-ID: <20250621050743.GA3007684@coredump.intra.peff.net>
In-Reply-To: <CAP8UFD27tQ3uhQW5zkPfFZSF=3FGEmi-rBYu3A_zZ8oNbUiNag@mail.gmail.com>

On Fri, Jun 20, 2025 at 04:08:32PM +0200, Christian Couder wrote:

Show 8 quoted lines

> > A post-commit hook that does *not* prevent your changes that do not
> > pass the "style-check" from getting committed, but does give you a
> > feedback that let you consider before moving forward?
> 
> 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.

I'm not sure I would want to make changes at the format-patch stage. If I am adjusting commits, I'd want those changes in my local commits, too. Then they'd be there if I re-roll, etc (plus they'd actually be tested when I run "make test"!). Ditto for folks using GGG, where they need to push the fully-realized commits.

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 current "make style" only looks at uncommitted changes in the working tree (and of course isn't interactive).

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

-Peff