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>
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>
We now have a GitHub Action to download and cache Azure Pipelines
artifacts (such as the `vcpkg` artifacts), hiding gnarly internals, and
also providing some robustness against network glitches. Let's use it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As mentioned in the Makefile and CMakeLists.txt: "When cross-compiling, define HOST_CPU as the canonical name of the CPU on which the built Git will run (for instance "x86_64")"
This commit sets the HOST_CPU variable since Git for Windows arm64 is cross-compiled from an amd64 host.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
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>
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>
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>
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 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>
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>
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>
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>
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>
