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

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