On 10/27/2017 04:49 PM, Jan Holesovsky wrote:
But still, I see the Thorsten's point why it would be easier for people
in many cases; that's why I proposed the 'automatic, but ending up as
an additional changeset' way, that at least gives a chance to inspect &
do something about that.
I'd propose to have three things:
1 A pre-commit--hook version of the clang-format check (that prevents
the commit if it fails) that runs iff clang-format is found locally.
(With the assumption that "core" committers will have clang-format
installed locally, especially if they commit directly without going via
Gerrit.)
2 A Gerrit version of the clang-format check that is run for every
Gerrit patch set, and sets some "Code-Style: -1/+1" Gerrit flag as
discussed in David's recent mail ("Gerrit Code-Style verification --
was ESC / Rome discussion ..."). (For the cases that pass through
Gerrit and that (1) above misses, like changes
from---casual---committers that do not have clang-format installed
locally, or direct edits in the Gerrit web UI.)
3 A Gerrit web UI button that allows to run clang-format on a specific
Gerrit change and produces a new patch set if necessary (somewhat
similar to the existing rebase button; useful for---casual---committers
that do not have clang-format installed locally, if (2) above marked
their change as "Code-Style: -1".)
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.