Supposedly, at this day and age, it is OK to use non-ascii file names.
Specifically, this is intended to allow such names for bugdocs, which
allows simpler testing of problems with handling those.
An alternative would be to rename bugdocs at runtime; but that still
requires that the target filesystem supports such names, so...
Change-Id: I25da2402f311d59c5777c4cd302147d6965dea5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160217
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...to avoid a error "Cannot run git diff-index. at .git/hooks/pre-commit line 51." that occures on Windows.
Change-Id: I868e87940f9fcef950970b59e8cbe747f80c7198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152830
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
and linux-links
This patch improve patch
9afc6b22e2 git-hooks:
overwrite the windows-links not with linux-links
The main problem with the previous patch is that
when an alias is set for git, this alias will not
map in the Shell script passed, better you
use a git-symlink.
The other problem was the behavior of cygwin-bash
and win-git-bash that is not always the same, e.g.
- winlnk=$(cmd /C ... 2>&1) it hang infinity,
line 123
- the 'ln' made not link, it only copy the files
Improving the FOR in ./git-hooks/README, when
you have the copied files, need a other del command
The patch can not set the windows-links, only output
the ./git-hooks/README
But in Win 11 should be possible, it is not needed
admin-rights for the 'mklink' command
Change-Id: Icecdb96e65fe2bba1270dfad2ac1af5af145925a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148462
Tested-by: Jenkins
Reviewed-by: Juergen Funk <juergen.funk_ml@cib.de>
Always when you call build or logerrit, then the windows-links
overwrite with linux-links, but when you using GIT for Windows
you need the windows-links.
This patch made a check it is using GIT for Windows, and check what
for link it is, when wrong link, it output the .git-hooks/README
Improve the check for links, when a link is set not need to set
the link anymore
In .git-hooks/README improve the FOR with delete of the wrong link
look here for GIT for Windows:
https://wiki.documentfoundation.org/Development/BuildingOnWindows/de#Cygwin_and_git
Change-Id: I9f6ef9aca316058ef74cb2b2d107236f03a2e2ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147458
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Those are used in basic/qa
Change-Id: Idf444bbd540d3f23450db1586489f27df64e09a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144582
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...to avoid misguided clang-format'ing of previously excluded files, as
discussed in the comment at
<https://gerrit.libreoffice.org/c/core/+/142387/4#message-ce27921261661fe7488ef0564657dbb5b42fb5fa>
"sc: factor out common code in make files".
(Though this still doesn't warn about cases where some excluded file got renamed
and the excludelist wasn't updated and the user already erroneously
clang-format'ed the renamed file before this commit attempt. Also, I don't
know how best to integrate this with libreoffice.autostyle, so just ignore
libreoffice.autostyle for now when any suspicious renames are detected.)
Change-Id: I8d176ce536548b67f5b2af100f579f362764b06b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142394
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
as egrep/fgrep is deprecated since long amd grep 3.8+ now actually warns
(e.g. "egrep: warning: egrep is obsolescent; using grep -E")
Change-Id: I5b10f05dffdd09081deb05cef974e3cdb2907315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139614
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This code was copy&paste from bin/ui-checkdomain.sh in
f3665d2a42
<Check UI interface domains in the git pre-commit hook>
and it was already wrong there.
Kudos to Julien Nabet for flagging it
Change-Id: Id2b16cf76f6e4f983dc59673b67ce369a84cffd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114762
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This will prevent bugs like tdf#141902 to happen
Change-Id: If81164c704ec17d3fee044aaa0ec9c16d474009e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114705
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
and update the version mentioned in our min req in the readme.xrm
follow up to
commit 0c9ccc7dbf
Author: Caolán McNamara <caolanm@redhat.com>
Date: Fri Oct 2 21:21:45 2020 +0100
raise min version of gtk to 3.20.0
Change-Id: Ibae55c97e1ee577f4b7435d124cda6a21005ad0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104692
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Even if hooks.allownonascii is set to true, the current code
compares "true\n" vs "true" and always rejects committing.
Change-Id: I75494f149db2537ad54230dd684f5dac9b43c8b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97213
Tested-by: Takeshi Abe <tabe@fixedpoint.jp>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
... are used in the right place
Change-Id: I49bfe2f03e519138ae78a7462afe98932a335365
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102264
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
when you using git for windows (faster) then the git-hooks
not work with "ln", it needs "mklink" from windows
Change-Id: I15981f44293186efd3fbaa5c1a044348034cef28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102032
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
For git worktree setups, the hooks sit with the original repo
(usually the initial clone). Worktrees with older version checkouts
then miss the blacklist->excludelist rename, and consequently fail.
Change-Id: I5f60fabc7d5856c74d93c4ada54f57574e0fd1a9
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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>
