Hi,
trying to figure out in which ways clang-format is (supposed to be) hooked up in our git-hooks. And what role it plays, yet.
There is a lint test, that so far never did something for me because it relies on a `.clang-format-scope` file (that is not in the tree?). Still, this check seems to be actively maintained.
And also a `util/lint/check-style` that is only hooked up if you run `make git-config` recently (I didn't, so I'm a little surprised). This one doesn't have a scope file, it seems?
What does each of these checks do?
Did anybody ever use the scope file? Is it used downstream somewhere?
Same as with `check-patch`, I believe we need either a white or black listing. Imagine you'd try to work on superiotool and clang-format (with its coreboot config) is run on that.
Nico
Am Sa., 16. März 2019 um 14:51 Uhr schrieb Nico Huber nico.h@gmx.de:
There is a lint test, that so far never did something for me because it relies on a `.clang-format-scope` file (that is not in the tree?). Still, this check seems to be actively maintained.
The idea was to slowly migrate the tree to automatic formatting, and to use the clang-format-scope file to support that: Once a directory is actively brought into compliance with the style enforced by clang-format we list it there to make sure that it doesn't fall out of compliance again, but without having to handle the entire tree at once (and having to rebase the entire set of open patches on Gerrit at once, for example).
Did anybody ever use the scope file? Is it used downstream somewhere?
That the file isn't used yet is mostly because that transition hasn't started yet, but Ron attempted to start with Risc-V at some point and I prepared to switch over the Getac mainboard ( https://review.coreboot.org/c/coreboot/+/31652). This commit both brings that part of the tree into compliance and - once merged - ensures that it remains so.
Since you started another thread, let's move this stuff over there.
Patrick
On 16.03.19 14:50, Nico Huber wrote:
And also a `util/lint/check-style` that is only hooked up if you run `make git-config` recently (I didn't, so I'm a little surprised). This one doesn't have a scope file, it seems?
Does nobody know this one? It seems like a campaign *against* clang- format because it currently blocks anyone with a new clone/gitconfig from committing without reformatting entire files.
e.g., if I do:
$ cd /tmp $ git clone https://review.coreboot.org/coreboot.git $ cd coreboot $ make gitconfig $ echo '/* foo */' >>util/superiotool/ite.c $ git add -u $ git commit -s -m bar
I get to scroll up nearly 1.5k lines to see this:
The following differences were found between the code to commit and the clang-format rules:
And the style enforced by *this currently active hook* sometimes doesn't comply with our rules and don't pass checkpatch.
Nico
On Thu, Mar 28, 2019 at 10:16:42PM +0100, Nico Huber wrote:
On 16.03.19 14:50, Nico Huber wrote:
And also a `util/lint/check-style` that is only hooked up if you run `make git-config` recently (I didn't, so I'm a little surprised). This one doesn't have a scope file, it seems?
Does nobody know this one? It seems like a campaign *against* clang- format because it currently blocks anyone with a new clone/gitconfig from committing without reformatting entire files.
e.g., if I do:
$ cd /tmp $ git clone https://review.coreboot.org/coreboot.git $ cd coreboot $ make gitconfig $ echo '/* foo */' >>util/superiotool/ite.c $ git add -u $ git commit -s -m bar
I get to scroll up nearly 1.5k lines to see this:
The following differences were found between the code to commit and
the clang-format rules:
And the style enforced by *this currently active hook* sometimes doesn't comply with our rules and don't pass checkpatch.
I started sending in some patches to coreboot over the past two weeks and have bumped into this. I wasn't sure what to do with it (nobody wants massive file reformats for a simple change), so I've had to run `git commit --no-verify` once to skip the check and write the commit message, and then `git commit --amend` to run the rest of the pre-commit hooks (like adding change id). I'm still not sure what the proper thing to do is.
Jacob Garber