Retrying clang-format

[cmdoug]

No real changes to src or etc folders, just ran the lines:

git ls-files 'src/*.cpp' 'src/*.hpp' 'src/*.c' 'src/*.h' | xargs -n1 clang-format -i
git ls-files 'etc/*.cpp' 'etc/*.hpp' 'etc/*.c' 'etc/*.h' | xargs -n1 clang-format -i

In the plugin folder, some /* clang-format off */ and /* clang-format on */ were added, then ran:

git ls-files 'plugin/*.cpp' 'plugin/*.hpp' 'plugin/*.c' 'plugin/*.h' | xargs -n1 clang-format -i

Ref: f715746

[cmdoug]

Note that I did essentially nothing here. From what I can tell, all credit is to @sgarnotel. Some questions for review:

• Should .clang-format also be enforced via GitHub Actions or is that overkill?
• This will wreck git blame. Do we want to avoid that? E.g. via --ignore-rev
• Also, to avoid further commits with huge diffs, might be worth asking: is the existing .clang-format exactly what we want?

[prj-]

1. There is currently no strict rule for merging, so there is not much to enforce.
2. There is no way around that, but anyway, the history is already messed up since around the release of version 4.
3. I guess the one which minimizes changes would be ideal.

[cmdoug]

Sounds good. In response to 3., do you (or the other developers) have any suggestions for alterations to .clang-format that would minimize changes while still cleaning up formatting issues? I just used the one already in the project.

[prj-]

Sorry for the unbelievably late answer, but reusing the current .clang-format is fine. The CI is currently broken, I had hoped to get an answer from @simonlegrand by now, but until then, I'm very wary of merging such a large PR.i

[cmdoug]

No worries. I agree that patience is a virtue with such a large PR. Also, since there is no functional change, there is no urgency for getting this merged. Perhaps this could be wrapped in with the next major release.