> 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

> "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

> 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...

> 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.

> 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?
>

> 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.

> 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"

> 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.

> 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"

> 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'

> 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

> 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.

> 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?

> 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?

> 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.

> 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.

> 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.

> 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