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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux