real symlinks require admin-rights or developer mode, and the other
fallback mechanisms won't work for the version of git that comes with
git-bash. Either spawning the process failes or worse it silently fails
and basically ignores the hook.
MSYS uses regular file copy when using "ln -s" which means to make sure
the current version of a hook is used the hooks need to replaced
everytime or the file contents need to be compared. When using hardlinks
instead it is enough to check whether the source and target share the
same inode.
Change-Id: Ib2e325048779828313afc7fc9d120661d55fc3a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177498
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
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>
This avoids "ln: failed to access '.git/hooks/foo': Not a directory"
console noise. The primary worktree's hooks are used in secondary
worktrees anyway.
Possibly using 'git rev-parse --git-dir', and putting hooks there
would be a better fix? No idea.
Change-Id: I846e065d017744e9d8dcee847d48bc1adc66d761
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143358
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Newer version of git has a --progress option to show the progress when running "git submodule update". This is useful in our ./g command expecially when we are building the code with l10n languages enabled and the network connection is slow. Without this I do not see where I am for the update process and may think it have died.
Change-Id: I4c9e1e9bccbd8e6ca2ea2b44f5b6d6d90cad1506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117922
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... where running './g pull -r' resulted in
ln: failed to create symbolic link '.git/modules/dictionaries/hooks/*': No such file or directory
ln: failed to create symbolic link '.git/modules/translations/hooks/*': No such file or directory
Change-Id: Ie0bd2eaca44f8b1a2ad2de9083bbefc779e213e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This reverts commit 27925032cd.
Conflicts:
g
According to vmiklos, that commit was meant to help with the following scenario:
Assume a dev uses submodules and uses plain `git pull && git submodule update`
instead of ./g. When they forget the "&& git submodule update" part and do
`git commit -a`, changes to the submodules were excluded from the commit.
However, when they do `git add -u && git commit` instead of `git commit -a`,
changes to the submodules /are/ included in the commit, despite `git status` or
`git diff` (both prior to `git add -u`) or `git diff --cached` (after `git add
-u`) not indicating that there are any changes to the submodules. I consider
that problem more confusing and severe than the problem that the commit solved.
Change-Id: I595eed3c1c04efd108be1ccd792d8d7bce72a345
Reviewed-on: https://gerrit.libreoffice.org/51155
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Change-Id: I50cb1a403d3aa34434e61a2a995ef043b2f1f82c
SC2086: Double quote to prevent globbing and word splitting.
SC2145: Argument mixes string and array. Use * or separate argument.
Reviewed-on: https://gerrit.libreoffice.org/37023
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Change-Id: I1814bc65c62af1a92a090127f1cfda8ad228936d
SC2002: Useless cat.
SC2045: Iterating over ls output is fragile.
SC2166: Prefer [ p ] || [ q ] as [ p -o q ] is not well defined.
SC2006: Use $(..) instead of legacy `..`
Reviewed-on: https://gerrit.libreoffice.org/36571
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
In 'g' shell script, we use grep to get substring from config_host.mk file.
When config_host.mk file contains non-ascii characters(e.g. Japanese),
this processing doesn't work.
As a result, some variables(SUBMODULES_CONFIGURED, REFERENCED_GIT, LINKED_GIT) will be
assigned to "Binary file (standard input) matches".
This is an error message of grep.
The problem will reproduce on Cygwin64 with Japanese locale.
With '-a' option, grep will work well, and 'g' shell script will work correctly.
Please refer the following commit,too.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0293ec98c92fd58a592f7dd86fbbf47e7b9195c6
Change-Id: If4e0b356173c8f442e3539ed343f441d87dbfd48
Reviewed-on: https://gerrit.libreoffice.org/16344
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
When config_host.mk contains non-ascii characters(e.g. Japanese ),
SRC_ROOT may contain an error message "Binary file (standard input)
matches") from grep, and SRC_ROOT may not contain path string.
With '-a' option, grep will work well.
Change-Id: Ifaada5f5a11939d624460cd8dcc57d93911ae790
Reviewed-on: https://gerrit.libreoffice.org/14491
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
1) submodule's .git is possibly a file now
2) just use the logerrit alias, as
- logerrit setup already set that up
- possibly otherwise the right ssh key is not picked up
Change-Id: I4fb355a7f7ec7d549d2b06367f4fd10d06086374
With slightly different semantics:
Instead of pointing at a previous checkout,
point at base directory of all repos.
Change-Id: I254ecc33071be53067c44610b030f737cf75a7ee
This is similar to --with-linked-git, but:
1) It uses git submodule update --reference, so it works with submodules.
2) The created repo is a true git repo, except that its object database
reuses the referenced repo's objects, so it's a real speedup when e.g.
translations are enabled.
I intentionally didn't just fixed --with-linked-git, to make it clear
this is more like git clone --reference, not git-new-workdir.
Change-Id: I7c9584bce3670fd1e175b90aded2435cfe78056d
Because either it's called from there, and then it's the current directory,
or otherwise the srcdir has no idea where the builddir is (or even how many
of them), and there's nothing to tell it.
Change-Id: I88c5fe8f015cc63a5aa7c327eb82ed751c3e8aa0
This patch allows to do
mkdir <build_dir>
cd <build_dir>
<src_root>/autogen.sh
make
Only the remaining dmake modules are poluting the <src_root>...
which will get eventually convererd to gmake...
Change-Id: Iefd64732fa12e096d554cff4eee6b777deb92338
Reviewed-on: https://gerrit.libreoffice.org/1273
Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
we use perl to determine the absolute path of argument thought to be
fiels. but sometime they are not file at all and that call 'fail'.
The code is meant to deal with such case, but
on some platform that produce a scary message on stderr in the
middle of the build log.
This hide these messages.
Change-Id: I52d43e0b26847ab091d76fd446a05c4d84836a77
Noel Grandin