[PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Johannes Schindelin via GitGitGadget]

In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
jobs. This patch series should fix it (lightly tested, but I don't have a
whole lot of build minutes on GitLab).

Johannes Schindelin (4):
  ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
  ci(gitlab,windows): preserve exclusions during dependency setup
  ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
  ci(gitlab,windows): provide GNU Rust's host-linker support

 .gitlab-ci.yml              |  5 ++++-
 ci/install-dependencies.ps1 | 22 ++++++++++++++++------
 2 files changed, 20 insertions(+), 7 deletions(-)


base-commit: d38352cd43ab9745686d697872408bc3249a153f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2233%2Fdscho%2Ffix-cargo-in-windows-gitlab-ci-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2233/dscho/fix-cargo-in-windows-gitlab-ci-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2233
-- 
gitgitgadget

[PATCH 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The minimal Git for Windows SDK already supplies Git and GCC. The
MinGW Makefile build needs the GNU Rust toolchain, not another Git
installation or Meson.

Let the dependency installer serve this configuration while keeping
the existing package set for MSVC builds.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index e3b367fa54..8c68fb0cfc 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -1,5 +1,6 @@
 param(
-    [string]$DownloadDirectory = '.dependencies'
+    [string]$DownloadDirectory = '.dependencies',
+    [switch]$Mingw
 )
 
 $ErrorActionPreference = 'Stop'
@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"
@@ -49,7 +61,3 @@ Invoke-Installer $gitInstaller @('-y', '-o"C:\Program Files\Git"')
 $mesonMsi = Get-Installer "meson.msi" `
     "https://github.com/mesonbuild/meson/releases/download/$MesonVersion/meson-$MesonVersion-64.msi"
 Invoke-Installer msiexec.exe @('/i', $mesonMsi, 'INSTALLDIR=C:\Meson', '/quiet', '/norestart')
-
-$rustMsi = Get-Installer "rust.msi" `
-    "https://static.rust-lang.org/dist/rust-$RustVersion-x86_64-pc-windows-msvc.msi"
-Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust', 'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
-- 
gitgitgadget

Re: [PATCH 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

[Patrick Steinhardt]

On Sat, Sep 19, 2026 at 12:12:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The minimal Git for Windows SDK already supplies Git and GCC. The
> MinGW Makefile build needs the GNU Rust toolchain, not another Git
> installation or Meson.

Huh, what's GNU Rust?

> Let the dependency installer serve this configuration while keeping
> the existing package set for MSVC builds.

Okay. What's implicit here is that we in fact don't use this script at
all at the current point in time for our MinGW build, we rather use the
"install-sdk.ps1" script. I assume it will be wired up in the next step,
so let's read on.

> diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> index e3b367fa54..8c68fb0cfc 100755
> --- a/ci/install-dependencies.ps1
> +++ b/ci/install-dependencies.ps1
> @@ -41,6 +42,17 @@ function Invoke-Installer {
>      }
>  }
>  
> +$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
> +$rustMsi = Get-Installer "rust-$rustTarget.msi" (
> +    "https://static.rust-lang.org/dist/" +
> +    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
> +Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
> +    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
> +
> +if ($Mingw) {
> +    return
> +}
> +
>  $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
>  $gitInstaller = Get-Installer "Git-Installer.exe" `
>      "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"

Okay, so installing Rust is the only thing we will want to do on both
MSVC and MinGW builds.

Patrick

Re: [PATCH 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

[Johannes Schindelin]

Hi Patrick,

On Thu, 24 Sep 2026, Patrick Steinhardt wrote:

> On Sat, Sep 19, 2026 at 12:12:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > The minimal Git for Windows SDK already supplies Git and GCC. The
> > MinGW Makefile build needs the GNU Rust toolchain, not another Git
> > installation or Meson.
> 
> Huh, what's GNU Rust?

Sorry, poor wording. I meant the Rust toolchain compatible with GCC (as
opposed to the Rust toolchain producing Visual C-compatible libraries).

Will reword. Using `git history reword`, thank you so much for that!

> > Let the dependency installer serve this configuration while keeping
> > the existing package set for MSVC builds.
> 
> Okay. What's implicit here is that we in fact don't use this script at
> all at the current point in time for our MinGW build, we rather use the
> "install-sdk.ps1" script. I assume it will be wired up in the next step,
> so let's read on.

Correct. Will clarify the commit message.

> > diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> > index e3b367fa54..8c68fb0cfc 100755
> > --- a/ci/install-dependencies.ps1
> > +++ b/ci/install-dependencies.ps1
> > @@ -41,6 +42,17 @@ function Invoke-Installer {
> >      }
> >  }
> >  
> > +$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
> > +$rustMsi = Get-Installer "rust-$rustTarget.msi" (
> > +    "https://static.rust-lang.org/dist/" +
> > +    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
> > +Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
> > +    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
> > +
> > +if ($Mingw) {
> > +    return
> > +}
> > +
> >  $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
> >  $gitInstaller = Get-Installer "Git-Installer.exe" `
> >      "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"
> 
> Okay, so installing Rust is the only thing we will want to do on both
> MSVC and MinGW builds.

Precisely (or as Claude would say: You're absolutely right!),
Johannes

[PATCH 2/4] ci(gitlab,windows): preserve exclusions during dependency setup

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Creating .git/info/exclude as a file with `New-Item` and `-Force`
truncates existing contents.

When install-dependencies.ps1 follows install-sdk.ps1, this discards
the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK
files as unignored build artifacts.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index 8c68fb0cfc..f6868dc670 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
 
 New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
 New-Item -Path .git/info -ItemType Directory -Force | Out-Null
-New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
+if (-not (Test-Path .git/info/exclude)) {
+    New-Item -Path .git/info/exclude -ItemType File | Out-Null
+}
 Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"
 
 function Get-Installer {
-- 
gitgitgadget

Re: [PATCH 2/4] ci(gitlab,windows): preserve exclusions during dependency setup

[Patrick Steinhardt]

On Sat, Sep 19, 2026 at 12:12:11PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> Creating .git/info/exclude as a file with `New-Item` and `-Force`
> truncates existing contents.
> 
> When install-dependencies.ps1 follows install-sdk.ps1, this discards
> the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK
> files as unignored build artifacts.

Okay, this confirms that it's indeed the plan to start calling this
script for MinGW builds, too.

> diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> index 8c68fb0cfc..f6868dc670 100755
> --- a/ci/install-dependencies.ps1
> +++ b/ci/install-dependencies.ps1
> @@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
>  
>  New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
>  New-Item -Path .git/info -ItemType Directory -Force | Out-Null
> -New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
> +if (-not (Test-Path .git/info/exclude)) {
> +    New-Item -Path .git/info/exclude -ItemType File | Out-Null
> +}
>  Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"

Makes sense.

Patrick

[PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

GitLab's MinGW job fails with "cargo: command not found":
https://gitlab.com/git-scm/git/-/jobs/16576450182

86909a94db5d (ci(windows): build with Rust, 2026-09-13) enabled Rust
in the shared CI configuration, but added the necessary setup only
for GitHub Actions.

The build needs Cargo to be reachable after the minimal SDK's login
profile replaces PATH. Installing the toolchain alone is not enough.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitlab-ci.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cd6fd4a504..3f24835500 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
   artifacts:
     paths:
       - artifacts
-- 
gitgitgadget

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Patrick Steinhardt]

On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index cd6fd4a504..3f24835500 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -133,8 +133,11 @@ build:mingw64:
>    before_script:
>      - *windows_before_script
>      - ./ci/install-sdk.ps1 -directory "git-sdk"
> +    - ./ci/install-dependencies.ps1 -Mingw

I wonder whether it would now make sense to also hoist "install-sdk.ps1"
into "install-dependencies.ps1" now.

>    script:
> -    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
> +    # The minimal SDK's profile resets PATH.
> +    - git-sdk/usr/bin/bash.exe -l -c
> +        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'

Are we sure that PATH cannot ever contain spaces or should we rather
quote here?

Patrick

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Johannes Schindelin]

Hi Patrick,

On Thu, 24 Sep 2026, Patrick Steinhardt wrote:

> On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index cd6fd4a504..3f24835500 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -133,8 +133,11 @@ build:mingw64:
> >    before_script:
> >      - *windows_before_script
> >      - ./ci/install-sdk.ps1 -directory "git-sdk"
> > +    - ./ci/install-dependencies.ps1 -Mingw
> 
> I wonder whether it would now make sense to also hoist "install-sdk.ps1"
> into "install-dependencies.ps1" now.

Honestly, I wouldn't. It is conceptually a different thing, the SDK brings
a ready-configured environment (which _partially_ ships dependencies,
that's right, but it's a Venn diagram, not a strict super set
relationship).

> >    script:
> > -    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
> > +    # The minimal SDK's profile resets PATH.
> > +    - git-sdk/usr/bin/bash.exe -l -c
> > +        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
> 
> Are we sure that PATH cannot ever contain spaces or should we rather
> quote here?

Ah, quoting in shell, what a wonderfully magical world. While you would be
correct that passing an unquoted `$PATH` as an _argument_ would cause
unwanted misinterpretation as multiple arguments instead of a single one,
_assigning variables_ is a completely different issue. Observe:

  $ x="Patrick Steinhardt"; x=$x=hello env | grep ^x=
  x=Patrick Steinhardt=hello

Wha...? It did _not_ split the $x at whitespace? No. In what must have
occurred as quite logical to the inventors of the Unix shell syntax,
interpolating unquoted variables in assignments does *not* split at
whitespace, unlike in other instances where unquoted variables are very
much split at whitespace.

Ciao,
Johannes

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Patrick Steinhardt]

On Thu, Sep 24, 2026 at 09:55:53PM +0200, Johannes Schindelin wrote:
> Hi Patrick,
> 
> On Thu, 24 Sep 2026, Patrick Steinhardt wrote:
> 
> > On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > index cd6fd4a504..3f24835500 100644
> > > --- a/.gitlab-ci.yml
> > > +++ b/.gitlab-ci.yml
> > > @@ -133,8 +133,11 @@ build:mingw64:
> > >    before_script:
> > >      - *windows_before_script
> > >      - ./ci/install-sdk.ps1 -directory "git-sdk"
> > > +    - ./ci/install-dependencies.ps1 -Mingw
> > 
> > I wonder whether it would now make sense to also hoist "install-sdk.ps1"
> > into "install-dependencies.ps1" now.
> 
> Honestly, I wouldn't. It is conceptually a different thing, the SDK brings
> a ready-configured environment (which _partially_ ships dependencies,
> that's right, but it's a Venn diagram, not a strict super set
> relationship).

Fair enough.

> > >    script:
> > > -    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
> > > +    # The minimal SDK's profile resets PATH.
> > > +    - git-sdk/usr/bin/bash.exe -l -c
> > > +        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
> > 
> > Are we sure that PATH cannot ever contain spaces or should we rather
> > quote here?
> 
> Ah, quoting in shell, what a wonderfully magical world. While you would be
> correct that passing an unquoted `$PATH` as an _argument_ would cause
> unwanted misinterpretation as multiple arguments instead of a single one,
> _assigning variables_ is a completely different issue. Observe:
> 
>   $ x="Patrick Steinhardt"; x=$x=hello env | grep ^x=
>   x=Patrick Steinhardt=hello
> 
> Wha...? It did _not_ split the $x at whitespace? No. In what must have
> occurred as quite logical to the inventors of the Unix shell syntax,
> interpolating unquoted variables in assignments does *not* split at
> whitespace, unlike in other instances where unquoted variables are very
> much split at whitespace.

Well, TIL :)

Patrick

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>> > Are we sure that PATH cannot ever contain spaces or should we rather
>> > quote here?
>> ...
> Well, TIL :)

Our coding guidelines share some blame.  As some implementations of
shells historically were buggy when assignment is combined with
modifers (e.g., "export var=val") and split the right hand side at
$IFS, we strongly encourage assignment to be written with right hand
side quoted even when you shouldn't have to.  Uniformly applying the
safer rule is easier on mere mortals than knowing and remembering
exactly when we do not have to quote and omitting the quote ;-).

[PATCH 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking
gitcore's build script:
https://gitlab.com/dscho/git1/-/jobs/16593470275

Although gitcore is a static library, Cargo first links `build.rs`
as a host executable. We omitted the GNU MSI's `Gcc` feature, which
supplies the required linker and platform libraries:
https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index f6868dc670..9b833b9370 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -49,7 +49,7 @@ $rustMsi = Get-Installer "rust-$rustTarget.msi" (
     "https://static.rust-lang.org/dist/" +
     "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
 Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
-    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+    "ADDLOCAL=Rustc,Cargo,Std$(if ($Mingw) { ',Gcc' })", '/quiet', '/norestart')
 
 if ($Mingw) {
     return
-- 
gitgitgadget

Re: [PATCH 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

[Patrick Steinhardt]

On Sat, Sep 19, 2026 at 12:12:13PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking
> gitcore's build script:
> https://gitlab.com/dscho/git1/-/jobs/16593470275
> 
> Although gitcore is a static library, Cargo first links `build.rs`
> as a host executable. We omitted the GNU MSI's `Gcc` feature, which
> supplies the required linker and platform libraries:
> https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs

Hm. Does that mean that we now have two versions of GCC available, once
via the MinGW environment and once via Rust?

Thanks!

Patrick

Re: [PATCH 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

[Johannes Schindelin]

Hi Patrick,

On Thu, 24 Sep 2026, Patrick Steinhardt wrote:

> On Sat, Sep 19, 2026 at 12:12:13PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking
> > gitcore's build script:
> > https://gitlab.com/dscho/git1/-/jobs/16593470275
> > 
> > Although gitcore is a static library, Cargo first links `build.rs`
> > as a host executable. We omitted the GNU MSI's `Gcc` feature, which
> > supplies the required linker and platform libraries:
> > https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs
> 
> Hm. Does that mean that we now have two versions of GCC available, once
> via the MinGW environment and once via Rust?

I don't think that Rust produces intermediate C by default, so no, this
would include a second version of GCC. It will just make sure that the
installed Rust version can produce libraries that GCC can link to.

Ciao,
Johannes

Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

> In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
> that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
> jobs. This patch series should fix it (lightly tested, but I don't have a
> whole lot of build minutes on GitLab).
>

I've created an MR [1] on our team repo for testing, I'll try to update
with newer versions (if any). The pipeline for this version is here [2].

[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
[2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081

> Johannes Schindelin (4):
>   ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
>   ci(gitlab,windows): preserve exclusions during dependency setup
>   ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
>   ci(gitlab,windows): provide GNU Rust's host-linker support
>
>  .gitlab-ci.yml              |  5 ++++-
>  ci/install-dependencies.ps1 | 22 ++++++++++++++++------
>  2 files changed, 20 insertions(+), 7 deletions(-)
>
>
> base-commit: d38352cd43ab9745686d697872408bc3249a153f
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2233%2Fdscho%2Ffix-cargo-in-windows-gitlab-ci-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2233/dscho/fix-cargo-in-windows-gitlab-ci-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2233
> --
> gitgitgadget

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Johannes Schindelin]

Hi Karthik,

On Sun, 20 Sep 2026, Karthik Nayak wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
> > that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
> > jobs. This patch series should fix it (lightly tested, but I don't have a
> > whole lot of build minutes on GitLab).
> >
> 
> I've created an MR [1] on our team repo for testing, I'll try to update
> with newer versions (if any). The pipeline for this version is here [2].
> 
> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
> [2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081

Thank you!

It looks as if the `build:mingw64` job succeeded, as planned (although it
should now probably say `build:ucrt64`?).

The `build:msvc-meson` job seems to have timed out trying to do something
with credentials, though...

Ciao,
Johannes

Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Karthik,
>
> On Sun, 20 Sep 2026, Karthik Nayak wrote:
>
>> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>> > In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
>> > that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
>> > jobs. This patch series should fix it (lightly tested, but I don't have a
>> > whole lot of build minutes on GitLab).
>> >
>>
>> I've created an MR [1] on our team repo for testing, I'll try to update
>> with newer versions (if any). The pipeline for this version is here [2].
>>
>> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
>> [2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081
>
> Thank you!
>
> It looks as if the `build:mingw64` job succeeded, as planned (although it
> should now probably say `build:ucrt64`?).
>
> The `build:msvc-meson` job seems to have timed out trying to do something
> with credentials, though...

Re-ran the job and it seems to now run as expected.

>
> Ciao,
> Johannes

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Johannes Schindelin]

Hi Karthik,

On Mon, 21 Sep 2026, Karthik Nayak wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 20 Sep 2026, Karthik Nayak wrote:
> >
> >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >>
> >> > In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
> >> > that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
> >> > jobs. This patch series should fix it (lightly tested, but I don't have a
> >> > whole lot of build minutes on GitLab).
> >> >
> >>
> >> I've created an MR [1] on our team repo for testing, I'll try to update
> >> with newer versions (if any). The pipeline for this version is here [2].
> >>
> >> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
> >> [2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081
> >
> > Thank you!
> >
> > It looks as if the `build:mingw64` job succeeded, as planned (although it
> > should now probably say `build:ucrt64`?).
> >
> > The `build:msvc-meson` job seems to have timed out trying to do something
> > with credentials, though...
> 
> Re-ran the job and it seems to now run as expected.

Seems that now some `test:msvc-meson` jobs failed. I had a closer look:
the failures happened during the cleanup phase. Apparently there is a
problematic change in the Runner image:

All failing jobs used Runner 19.4.0~pre.2085.g4d3dddee. Its cleanup code
(https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L2081)
calls `writeClearGitCredentials()`, which runs `git credential reject`:
https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L758

However, this `git credential reject` then calls _Git Credential Manager_,
which assumes that it is running interactively. And that there is anything
to reject. And therefore it waits for the user to react to the open
dialog, but there is no user, so it times out after two hours.

The successfully-retried build
(https://gitlab.com/gitlab-org/git/-/jobs/16625727899) and the passing
test slice 3 (https://gitlab.com/gitlab-org/git/-/jobs/16604448474) used
Runner **18.8.0**, whose cleanup code
(https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v18.8.0/shells/abstract.go#L1699)
lacks that credential-clearing call.

Might be worth pointing that out to your colleagues who are in charge of
that Runner image?

Ciao,
Johannes

Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Karthik,
>
> On Mon, 21 Sep 2026, Karthik Nayak wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On Sun, 20 Sep 2026, Karthik Nayak wrote:
>> >
>> >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> >>
>> >> > In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
>> >> > that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
>> >> > jobs. This patch series should fix it (lightly tested, but I don't have a
>> >> > whole lot of build minutes on GitLab).
>> >> >
>> >>
>> >> I've created an MR [1] on our team repo for testing, I'll try to update
>> >> with newer versions (if any). The pipeline for this version is here [2].
>> >>
>> >> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
>> >> [2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081
>> >
>> > Thank you!
>> >
>> > It looks as if the `build:mingw64` job succeeded, as planned (although it
>> > should now probably say `build:ucrt64`?).
>> >
>> > The `build:msvc-meson` job seems to have timed out trying to do something
>> > with credentials, though...
>>
>> Re-ran the job and it seems to now run as expected.
>
> Seems that now some `test:msvc-meson` jobs failed. I had a closer look:
> the failures happened during the cleanup phase. Apparently there is a
> problematic change in the Runner image:
>
> All failing jobs used Runner 19.4.0~pre.2085.g4d3dddee. Its cleanup code
> (https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L2081)
> calls `writeClearGitCredentials()`, which runs `git credential reject`:
> https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L758
>
> However, this `git credential reject` then calls _Git Credential Manager_,
> which assumes that it is running interactively. And that there is anything
> to reject. And therefore it waits for the user to react to the open
> dialog, but there is no user, so it times out after two hours.
>
> The successfully-retried build
> (https://gitlab.com/gitlab-org/git/-/jobs/16625727899) and the passing
> test slice 3 (https://gitlab.com/gitlab-org/git/-/jobs/16604448474) used
> Runner **18.8.0**, whose cleanup code
> (https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v18.8.0/shells/abstract.go#L1699)
> lacks that credential-clearing call.
>
> Might be worth pointing that out to your colleagues who are in charge of
> that Runner image?
>

I have no idea about this, but have forwarded the message to the
appropriate team. Hopefully we see some resolution. Thanks for the
debugging!

Karthik
> Ciao,
> Johannes

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

[PATCH v2 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Johannes Schindelin via GitGitGadget]

In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
jobs. This patch series should fix it (lightly tested, but I don't have a
whole lot of build minutes on GitLab).

Changes since v1:

 * Reworded the commit messages to clarify previously confusing statements.

Johannes Schindelin (4):
  ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
  ci(gitlab,windows): preserve exclusions during dependency setup
  ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
  ci(gitlab,windows): provide GNU Rust's host-linker support

 .gitlab-ci.yml              |  5 ++++-
 ci/install-dependencies.ps1 | 22 ++++++++++++++++------
 2 files changed, 20 insertions(+), 7 deletions(-)


base-commit: d38352cd43ab9745686d697872408bc3249a153f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2233%2Fdscho%2Ffix-cargo-in-windows-gitlab-ci-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2233/dscho/fix-cargo-in-windows-gitlab-ci-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2233

Range-diff vs v1:

 1:  6a389b2bad ! 1:  cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
     @@ Metadata
       ## Commit message ##
          ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
      
     -    The minimal Git for Windows SDK already supplies Git and GCC. The
     -    MinGW Makefile build needs the GNU Rust toolchain, not another Git
     -    installation or Meson.
     +    The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
     +    Makefile build needs the Rust toolchain that targets GCC (as opposed to
     +    the more common MSVC one), not another Git installation or Meson.
      
     -    Let the dependency installer serve this configuration while keeping
     -    the existing package set for MSVC builds.
     +    Prepare the `install-dependencies.ps1` script to be able to install the
     +    GCC-targeting Rust toolchain.
      
          Assisted-by: GPT-6
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
 2:  8855c25128 = 2:  19a4d93181 ci(gitlab,windows): preserve exclusions during dependency setup
 3:  57a83d15fd = 3:  6703fa0349 ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
 4:  1ed79f00cf ! 4:  5310afcdf9 ci(gitlab,windows): provide GNU Rust's host-linker support
     @@ Commit message
          https://gitlab.com/dscho/git1/-/jobs/16593470275
      
          Although gitcore is a static library, Cargo first links `build.rs`
     -    as a host executable. We omitted the GNU MSI's `Gcc` feature, which
     +    as a host executable. We omitted the Rust MSI's `Gcc` feature, which
          supplies the required linker and platform libraries:
          https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs
      

-- 
gitgitgadget

[PATCH v2 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
Makefile build needs the Rust toolchain that targets GCC (as opposed to
the more common MSVC one), not another Git installation or Meson.

Prepare the `install-dependencies.ps1` script to be able to install the
GCC-targeting Rust toolchain.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index e3b367fa54..8c68fb0cfc 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -1,5 +1,6 @@
 param(
-    [string]$DownloadDirectory = '.dependencies'
+    [string]$DownloadDirectory = '.dependencies',
+    [switch]$Mingw
 )
 
 $ErrorActionPreference = 'Stop'
@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"
@@ -49,7 +61,3 @@ Invoke-Installer $gitInstaller @('-y', '-o"C:\Program Files\Git"')
 $mesonMsi = Get-Installer "meson.msi" `
     "https://github.com/mesonbuild/meson/releases/download/$MesonVersion/meson-$MesonVersion-64.msi"
 Invoke-Installer msiexec.exe @('/i', $mesonMsi, 'INSTALLDIR=C:\Meson', '/quiet', '/norestart')
-
-$rustMsi = Get-Installer "rust.msi" `
-    "https://static.rust-lang.org/dist/rust-$RustVersion-x86_64-pc-windows-msvc.msi"
-Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust', 'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
-- 
gitgitgadget

[PATCH v2 2/4] ci(gitlab,windows): preserve exclusions during dependency setup

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Creating .git/info/exclude as a file with `New-Item` and `-Force`
truncates existing contents.

When install-dependencies.ps1 follows install-sdk.ps1, this discards
the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK
files as unignored build artifacts.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index 8c68fb0cfc..f6868dc670 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
 
 New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
 New-Item -Path .git/info -ItemType Directory -Force | Out-Null
-New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
+if (-not (Test-Path .git/info/exclude)) {
+    New-Item -Path .git/info/exclude -ItemType File | Out-Null
+}
 Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"
 
 function Get-Installer {
-- 
gitgitgadget

[PATCH v2 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

GitLab's MinGW job fails with "cargo: command not found":
https://gitlab.com/git-scm/git/-/jobs/16576450182

86909a94db5d (ci(windows): build with Rust, 2026-09-13) enabled Rust
in the shared CI configuration, but added the necessary setup only
for GitHub Actions.

The build needs Cargo to be reachable after the minimal SDK's login
profile replaces PATH. Installing the toolchain alone is not enough.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitlab-ci.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cd6fd4a504..3f24835500 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
   artifacts:
     paths:
       - artifacts
-- 
gitgitgadget

[PATCH v2 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking
gitcore's build script:
https://gitlab.com/dscho/git1/-/jobs/16593470275

Although gitcore is a static library, Cargo first links `build.rs`
as a host executable. We omitted the Rust MSI's `Gcc` feature, which
supplies the required linker and platform libraries:
https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 ci/install-dependencies.ps1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
index f6868dc670..9b833b9370 100755
--- a/ci/install-dependencies.ps1
+++ b/ci/install-dependencies.ps1
@@ -49,7 +49,7 @@ $rustMsi = Get-Installer "rust-$rustTarget.msi" (
     "https://static.rust-lang.org/dist/" +
     "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
 Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
-    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+    "ADDLOCAL=Rustc,Cargo,Std$(if ($Mingw) { ',Gcc' })", '/quiet', '/norestart')
 
 if ($Mingw) {
     return
-- 
gitgitgadget

Re: [PATCH v2 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Patrick Steinhardt]

On Thu, Sep 24, 2026 at 08:01:49PM +0000, Johannes Schindelin via GitGitGadget wrote:
> Range-diff vs v1:
> 
>  1:  6a389b2bad ! 1:  cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
>      @@ Metadata
>        ## Commit message ##
>           ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
>       
>      -    The minimal Git for Windows SDK already supplies Git and GCC. The
>      -    MinGW Makefile build needs the GNU Rust toolchain, not another Git
>      -    installation or Meson.
>      +    The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
>      +    Makefile build needs the Rust toolchain that targets GCC (as opposed to
>      +    the more common MSVC one), not another Git installation or Meson.

By the way, are there plans to eventually include Rust as part of the
GfW SDK? Just asking out of curiosity.

Overall I'm happy with this version, thanks!

Patrick

Re: [PATCH v2 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

Hi Patrick,

On Mon, 28 Sep 2026, Patrick Steinhardt wrote:

> On Thu, Sep 24, 2026 at 08:01:49PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > Range-diff vs v1:
> > 
> >  1:  6a389b2bad ! 1:  cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
> >      @@ Metadata
> >        ## Commit message ##
> >           ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
> >       
> >      -    The minimal Git for Windows SDK already supplies Git and GCC. The
> >      -    MinGW Makefile build needs the GNU Rust toolchain, not another Git
> >      -    installation or Meson.
> >      +    The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
> >      +    Makefile build needs the Rust toolchain that targets GCC (as opposed to
> >      +    the more common MSVC one), not another Git installation or Meson.
> 
> By the way, are there plans to eventually include Rust as part of the
> GfW SDK? Just asking out of curiosity.

I'm still agonizing over that. There is now this new `sha1dc` Rust crate I
want to integrate (patch series about to land), therefore I need to get
going with including Rust in Git for Windows' SDK. But it's not looking so
rosy! As described in the PR to include Rust in Git for Windows at
https://github.com/git-for-windows/git-sdk-64/pull/132, the addition comes
at the price of roughly 110MB.

Given that `git-sdk-x86_75-minimal.tar.zst` weighs just under 70MB (see
https://github.com/git-for-windows/git-sdk-64/releases/ci-artifacts), that
would more than _double_ its size!

So I'm really torn between including Rust (and having a strict subset of
the same setup in CI as is used to build Git for Windows releases) or
alternatively stick with the current strategy: Expect the correct Rust
toolchain to be installed separately in CI.

On GitHub Actions, Rust is basically already there, and we'd save a 110MB
extra download for _ever_ `win-*` job (of which there are _a lot_ on any
given day).

But GitLab runners do not (yet?) come with Rust preinstalled, so... 🤷

> Overall I'm happy with this version, thanks!

Thanks!
Johannes

Re: [PATCH v2 0/4] gitlab-ci: fix the cargo invocation in the Windows job

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Thu, Sep 24, 2026 at 08:01:49PM +0000, Johannes Schindelin via GitGitGadget wrote:
>> Range-diff vs v1:
>> 
>>  1:  6a389b2bad ! 1:  cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
>>      @@ Metadata
>>        ## Commit message ##
>>           ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
>>       
>>      -    The minimal Git for Windows SDK already supplies Git and GCC. The
>>      -    MinGW Makefile build needs the GNU Rust toolchain, not another Git
>>      -    installation or Meson.
>>      +    The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
>>      +    Makefile build needs the Rust toolchain that targets GCC (as opposed to
>>      +    the more common MSVC one), not another Git installation or Meson.
>
> By the way, are there plans to eventually include Rust as part of the
> GfW SDK? Just asking out of curiosity.
>
> Overall I'm happy with this version, thanks!
>
> Patrick

Thanks for writing and reviewing, both of you.  Let me mark the
topic for 'next'.