This mainly replaces the whole AWK code with the git helper
"interpret-trailers", which was added in git v2.2 end of 2014.
It also moves the argument checks from the original Gerrit hook
to the front of our tests to verify the script arguments.
Change-Id: I38c831bf7c9d399419a598d6966e48166d31ea6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87369
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
To the up to date version that is set up by e.g. 'git review -s' from
gerrit.libreoffice.org. Should help with \c in commit messages.
Change-Id: I42508f6f5bbb6fa70357694fcc820ed9a22f3b0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87347
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It was added with 60f200caa4 "git-hooks: Copy them
from the build repo", but I don't see its purpose, and it caused trouble for me
now when trying to commit <https://gerrit.libreoffice.org/67672> "Merge in
Flatpak improvements".
Change-Id: I922b5be87549793466f99db8b12be6081e683292
Reviewed-on: https://gerrit.libreoffice.org/67674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And also for a dangerous setting in the configuration that hides the
changes from you.
Change-Id: I99bad8024baf7048696d9602e857c253c20cb5c2
Reviewed-on: https://gerrit.libreoffice.org/63389
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Don't just tell the problem but hint how to fix it.
Change-Id: I9d079ee7d4ed61266e22a3fa21efe10366724645
Reviewed-on: https://gerrit.libreoffice.org/49471
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
git log --author="Your"
confirms that this happens in practice.
Change-Id: I48633bc9154ebc66fc022938831057bdc3ff76b3
Reviewed-on: https://gerrit.libreoffice.org/47892
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Consistently only assign something to $clang_format if it's a good
version, and also consistently return undef if we found no good version.
Change-Id: Iadbbb56a5c15dfaeec5c80e3cc8fcc78b787c04b
Reviewed-on: https://gerrit.libreoffice.org/46489
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
09:28 <@sberg> vmiklos, I think I ran into a scenario last night where I had
both `git add`-ed and non-added changes in a non-blacklisted file, and the
non-added changes violated clang-format (and the added ones did not), and the
commit hook complained
So make sure we validate the index version, not the filesystem one.
(And modify a formatted file to trigger CI validation of the hook change
itself.)
Change-Id: I6431b35ac50dd03741104b5709c5195d6ff28632
Reviewed-on: https://gerrit.libreoffice.org/46368
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
translations.git failed with "Can't locate ClangFormat.pm in @INC (you
may need to install the ClangFormat module)".
Change-Id: Ibbe051c1cb4c1200da58821589b8271434b1f9a6
Reviewed-on: https://gerrit.libreoffice.org/45020
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
- factor out common code to a shared module, and quote path to the
clang-format binary, just in case.
- add a new check-last-commit script that is the CI equivalent of the
exiting git pre-commit hook, but this one handles lack of clang-format
as an error, not as a warning.
- $LODE_HOME/opt/bin is supposed to be in PATH already, so not
mentioning LODE_HOME in ClangFormat::find() explicitly.
- if both COMPILER_PLUGINS and LODE_HOME is set, invoke
solenv/clang-format/check-last-commit as part of 'make check'
To test these changes as part of CI, fix a single style violation in an
already committed, non-blacklisted file.
This depends on the lode.git commit
496123bcae28e06c6d6aeda39a5afd1e1fb1fd98 (utils_Linux: install
clang-format in the Jenkins case, 2017-11-16), otherwise erroring out on
a not installed clang-format as part of the build would be a problem.
Change-Id: Ib3110826194ff78a7f1bed1c3796147e92ccb3ba
Reviewed-on: https://gerrit.libreoffice.org/44939
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Restrict the git hook further to only enforce style in case the found
clang-format binary's version matches to avoid output differences with
different clang-format version.
While at it, move the blacklist reading after the version check to speed
up committing a bit when no local enforcement happens.
Also add a simple script to list formatted files, since the blacklist is
large enough that doing it naively from the shell is too slow.
Change-Id: I0bc05961d262cc6bc91c6efdd1b91994ecfc6940
Reviewed-on: https://gerrit.libreoffice.org/44662
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
- The actual blacklist has to be generated with
solenv/clang-format/generate-style-blacklist.sh in a separate commit.
- .clang-format is from
<https://lists.freedesktop.org/archives/libreoffice/2014-August/062802.html>,
except:
- the commented out lines are removed
- Standard is Cpp11 instead of Cpp03
- explicitly avoid sorting includes (requested during ESC meeting
2017-10-11)
- no indentation inside namespaces (lots of existing code in sc wants this)
- The git hooks prints a diff when the style is violated, along with a
command to fix up the violation automatically. It also enforces style
only in new files and ignores all files listed in the blacklist.
- To avoid introducing one more hard-to-setup build dependency for new
developers, help them two ways:
- if clang-format is not installed, provide pre-built binaries for
Linux/Windows/macOS
- download/install of these binaries are printed as cmdline
instructions, similar to how we have our own 'make' on Windows
- As per ESC call 2017-11-02, currently don't do any checks if
clang-format is not installed (as a first step).
Change-Id: Iaa139c396337e8734aa1853305d808438260c41a
Reviewed-on: https://gerrit.libreoffice.org/43736
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This pre-commit hook prevents the commit of ui files with tooltip_markup property
Change-Id: I70d6f90fc36e782c290f35f0cc9415b9fa96495b
Signed-off-by: Marina Latini <marina@studiostorti.com>
Reviewed-on: https://gerrit.libreoffice.org/31735
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Muhammet Kara <muhammet.kara@pardus.org.tr>
Tested-by: Muhammet Kara <muhammet.kara@pardus.org.tr>
Reviewed-by: jan iversen <jani@documentfoundation.org>
The comment provided by git starts lines with '# ' (space or tab),
so warn if a line starts with # not followed by a space. It's most
likely something like '#ifdef UNX' or AOO's '#i103131#'. We already
have commits where git silently stripped off such lines.
Change-Id: Ic366d8ee64207edb8bb2fb1ef3a6a192f55872d8
