This is needed for the next change, where we add HOST_CPU support to the
CMake definition.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This simplifies the workflow dramatically.
Note that we have to reinstate that `/usr/bin/git` hack (a shell script
that simply redirects to `/mingw64/bin/git.exe`) in the `pkg` job
manually, since we no longer cache the `build-installers` artifact
_after_ installing that hack in `bundle-artifacts`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git's regular Makefile mentions that HOST_CPU should be defined when cross-compiling Git: 37796bca76/Makefile (L438-L439)
This is then used to set the GIT_HOST_CPU variable when compiling Git: 37796bca76/Makefile (L1337-L1341)
Then, when the user runs `git version --build-options`, it returns that value: 37796bca76/help.c (L658)
This commit adds the same functionality to the CMake configuration. Users can now set -DHOST_CPU= to set the target architecture.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
We cannot just check out the current revision: The user might have
overridden `REPOSITORY` and `REF` via the workflow dispatch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since there is no GCM Core for ARM64, let's just install a simple shell
script that calls the i686 version for now.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This workflow needs to be triggered manually, and it offers to specify a
couple input parameters. But none of them are required. Make that
explicit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the user asked for `installer-x86_64`, there is no point in
building `pkg-i686` or `build-arm64`; Let's be a bit smarter about this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When building the Pacman packages, we technically do not need the full
`build-installers` artifact (which is substantially larger than the
`makepkg-git` artifact). However, the former is already cached and
includes the latter's files. And it is _so_ much faster to download the
cached (larger) artifact than to download the smaller `makepkg-git`
artifact from Azure Pipelines.
Suggested-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The workflow allows users to restrict what parts are being built. For
example, `installer-i686` will build only the 32-bit installer, not the
64-bit one nor any MinGit flavor.
However, this logic was not extended when introducing support for ARM64:
Instead, we _also_ built the ARM64 installer when the user asked for
`installer-i686`.
Let's allow restricting to `installer-i686` _without_ building the ARM64
version, and allow restricting to `installer-arm64` _just_ for the ARM64
version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is a bit expensive to fetch just the git-sdk-64-build-installers
artifact from Azure Pipelines and then to unpack it (takes some 6-7
minutes, typically). Let's cache it if possible.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GitHub workflows run in agents that have quite a bit of stuff in their
`PATH`, e.g. Chocolatey. To make sure that those bits and pieces are
_not_ used to build the artifacts, let's whittle down the `PATH` to
contain the bare minimum.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The archive and MinGit variants really get bloated because they handle
those as straight copies instead of hard-links.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With this change, users can specify the branch and repository from which
they want to build Git for Windows' artifacts, via the `ref` and
`repository` inputs.
This allows e.g. building `refs/heads/seen` of `git/git` (even if no
`git-artifacts` workflow is configured in that repository), or
`refs/pull/<number>/merge` for a given Pull Request.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Users can now specify which artifacts they want to build, via the
`build_only` input, which is a space-separated list of artifacts. For
example, `installer portable` will build `installer-x86_64`,
`installer-i686`, `portable-x86_64` and `portable-i686`, and an empty or
unset value will build all artifacts.
Please note that the `mingw-w64-git` packages are built always, as it
would be tricky to figure out when they need to be built (for example,
`build_only=portable-x86_64` technically does not need `pkg-i686` to be
built, while `build_only=portable` does).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The two NuGet artifact exists only in the 64-bit version. So let's make
them in a separate, non-matrix job.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the secrets `CODESIGN_P12` and `CODESIGN_PASS` are set, the
workflow will now code-sign the `.exe` files contained in the package.
This should help with a few anti-malware programs, at least when the
certificate saw some action and gained trust.
Note: `CODESIGN_P12` needs to be generated via
cat <certificate>.p12 | base64 | tr '\n' %
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This expects the `GPGKEY` and `PRIVGPGKEY` secrets to be set in the
respective GitHub repository.
The `GPGKEY` value should be of the form
<short-key> --passphrase <pass> --yes --batch --no-tty --pinentry-mode loopback --digest-algo SHA256
and the `PRIVGPGKEY` should be generated via
gpg --export-secret-keys | base64 | tr '\n' %
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows uses MSYS2 as base system, and therefore the Git
binaries are bundled as Pacman package.
This workflow allows building the 64-bit version of this package (which
is called `mingw-w64-x86_64-git`).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are no Windows/ARM64 agents in GitHub Actions yet, therefore we
just skip adjusting the `vs-test` job for now.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In this context, a "feature" is a dependency combined with its own
dependencies.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The vcpkg downloads may not succeed. Warn careful readers of the time out.
A simple retry will usually resolve the issue.
Signed-off-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The vcpkg_install batch file depends on the availability of a
working Git on the CMD path. This may not be present if the user
has selected the 'bash only' option during Git-for-Windows install.
Detect and tell the user about their lack of a working Git in the CMD
window.
Fixes#2348.
A separate PR https://github.com/git-for-windows/build-extra/pull/258
now highlights the recommended path setting during install.
Signed-off-by: Philip Oakley <philipoakley@iee.email>
A recent upstream topic introduced checks for certain Git commands that
prevent them from deleting the current working directory, introducing
also a regression test that ensures that commands such as `git version`
_can_ run without a current working directory.
While technically not possible on Windows via the regular Win32 API, we
do run the regression tests in an MSYS2 Bash which uses a POSIX
emulation layer (the MSYS2/Cygwin runtime) where a really evil hack
_does_ allow to delete a directory even if it is the current working
directory.
Therefore, Git needs to be prepared for a missing working directory,
even on Windows.
This issue was not noticed in upstream Git because there was no caller
that tried to discover a Git directory with a deleted current working
directory in the test suite. But in the microsoft/git fork, we do want
to run `pre-command`/`post-command` hooks for every command, even for
`git version`, which means that we make precisely such a call. The bug
is not in that `pre-command`/`post-command` feature, though, but in
`mingw_getcwd()` and needs to be addressed there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch -h" incorrectly said "--track[=direct|inherit]",
implying that "--trackinherit" is a valid option, which has been
corrected.
* js/branch-track-inherit:
branch,checkout: fix --track usage strings
FreeBSD 13.0 headers have unconditional dependency on C11 language
features, and adding -std=gnu99 to DEVELOPER_CFLAGS would just
break the developer build.
* jc/freebsd-without-c99-only-build:
Makefile: FreeBSD cannot do C99-or-below build
As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a
list of allowed parameters is not recommended. Both git-branch and
git-checkout were changed in d311566 (branch: add flags and config to
inherit tracking, 2021-12-20) to use this discouraged combination for
their --track flags.
Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp
to simply be "mode". Users may discover allowed values in the manual
pages.
[1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In "make DEVELOPER=YesPlease" builds, we try to help developers to
catch as many potential issues as they can by using -Wall and
turning compilation warnings into errors. In the same spirit, we
recently started adding -std=gnu99 to their CFLAGS, so that they can
notice when they accidentally used language features beyond C99.
It however turns out that FreeBSD 13.0 mistakenly uses C11 extension
in its system header files regardless of what __STDC_VERSION__ says,
which means that the platform (unless we tweak their system headers)
cannot be used for this purpose.
It seems that -std=gnu99 is only added conditionally even in today's
config.mak.dev, so it is fine if we dropped -std=gnu99 from there.
Which means that developers on FreeBSD cannot participate in vetting
use of features beyond C99, but there are developers on other
platforms who will, so it's not too bad.
We might want a more "fundamental" fix to make the platform capable
of taking -std=gnu99, like working around the use of unconditional
C11 extension in its system header files by supplying a set of
"replacement" definitions in our header files. We chose not to
pursue such an approach for two reasons at this point:
(1) The fix belongs to the FreeBSD project, not this project, and
such an upstream fix may happen hopefully in a not-too-distant
future.
(2) Fixing such a bug in system header files and working it around
can lead to unexpected breakages (other parts of their system
header files may not be expecting to see and do not work well
with our "replacement" definitions). This close to the final
release of this cycle, we have no time for that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adjust build on RHEL 7 to explicitly ask C99 support and use
the fallback implementation of uncompress2 we ship.
* da/rhel7-lacks-uncompress2-and-c99:
build: centos/RHEL 7 ships with an older gcc and zlib
GCC 4.8.5 is the default system compiler on centos7/RHEL7.
This version requires -std=c99 to enable c99 support.
zlib 1.2.7 on centos7/rhel7 lacks uncompress2().
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we interpolated paths in config variables that start with a
forward-slash as relative to the runtime prefix. This was not portable
and has been replaced with `%(prefix)/`.
Let's warn users when they use the now-deprecated form.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch re-adds the deprecated --stdin/-z options to `git
reset`. Those patches were overridden by a different set of options in
the upstream Git project before we could propose `--stdin`.
We offered this in MinGit to applications that wanted a safer way to
pass lots of pathspecs to Git, and these applications will need to be
adjusted.
Instead of `--stdin`, `--pathspec-from-file=-` should be used, and
instead of `-z`, `--pathspec-file-nul`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch allows third-party tools to call `git status
--no-lock-index` to avoid lock contention with the interactive Git usage
of the actual human user.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A fix for calling `vim` in Windows Terminal caused a regression and was
reverted. We partially un-revert this, to get the fix again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We need to trim \r from the output of 'ssh-keygen -Y find-principals' on
Windows, or we end up calling 'ssh-keygen -Y verify' with a bogus signer
identity. ssh-keygen.c:2841 contains a call to puts(3), which confirms this
hypothesis. Signature verification passes with the fix.
Signed-off-by: pedro martelletto <pedro@yubico.com>
