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>
This commit adds a step called "initialize vcpkg" to the GitHub Actions
workflow, because we need some build scripts from vcpkg that aren't
present in our vcpkg artifacts from Azure Pipelines.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
In f1f5dff9e7 (cmake: installation support for git, 2020-06-26), we
added support for the CMake equivalent of `make install` that makes
use of multiple targets within one invocation of `install(TARGETS ...).
This is totally fine according to CMake's documentation at
https://cmake.org/cmake/help/latest/command/install.html#command:install).
And this was still fine even after ecf7ee3cd5 (cmake(install):
include vcpkg dlls, 2021-01-08) where we started to use `vcpkg`'s CMake
scripts to ensure that the `.dll` files of Git's dependencies are also
installed.
However, with a recent update of `vcpkg`, the handling of local
dependencies was changed in a way that is incompatible with our CMake
definition. The symptom looks like this:
CMake Error at <worktree>/compat/vcbuild/vcpkg/scripts/buildsystems/vcpkg.cmake:734 (get_target_property):
get_target_property() called with non-existent target "git;git-shell".
Call Stack (most recent call first):
<worktree>/compat/vcbuild/vcpkg/scripts/buildsystems/vcpkg.cmake:784 (x_vcpkg_install_local_dependencies)
CMakeLists.txt:821 (install)
The apparent reason for this breakage is that the `vcpkg` changes in
https://github.com/microsoft/vcpkg/commit/1bb5ea10a3 no longer allows an
arbitrary number of targets to be specified in `install(TARGETS ...)`.
Let's work around this by feeding the target individually to the
`install(TARGETS ...)` function.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This merges the current version of the patch that tries to address Git
GUI's problems with intent-to-add files.
This patch will likely be improved substantially before it is merged
into Git GUI's main branch, but we want to have _something_ resembling a
fix already in Git for Windows v2.29.0.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch allows `add -p` and `add -i` with a large number of
files. It is kind of a hack that was never really meant to be
upstreamed. Let's see if we can do better in the built-in `add -p`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In MSYS2, we have two Python interpreters at our disposal, so we can
include the Python stuff in the build.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make `git config --system` work like you think it should on Windows: it
should edit the file that is located in `<Git>\etc\gitconfig`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch teaches `git clean` to respect NTFS junctions and Unix
bind mounts: it will now stop at those boundaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch avoids spawning `gzip` when asking `git archive` to
create `.tar.gz` files.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When compiling Git with a runtime prefix (so that it can be installed
into any location, finding its libexec/ directory relative to the
location of the `git` executable), it is convenient to provide
"absolute" Unix-y paths e.g. for http.sslCAInfo, and have those absolute
paths be resolved relative to the runtime prefix.
This patch makes it so for Windows. It is up for discussion whether we
want this for other platforms, too, as long as building with
RUNTIME_PREFIX.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch allows us to specify absolute paths without the drive
prefix e.g. when cloning.
Example:
C:\Users\me> git clone https://github.com/git/git \upstream-git
This will clone into a new directory C:\upstream-git, in line with how
Windows interprets absolute paths.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These fixes were necessary for Sverre Rabbelier's remote-hg to work,
but for some magic reason they are not necessary for the current
remote-hg. Makes you wonder how that one gets away with it.
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 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>
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>
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>
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>
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>
