Hi,
On Sat, 29 Apr 2017, Johannes Sixt wrote:
> Am 29.04.2017 um 02:15 schrieb Ramsay Jones:
> >
> > On 28/04/17 20:54, Johannes Sixt wrote:
> > > Am 28.04.2017 um 05:09 schrieb Junio C Hamano:
> > > > Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> writes:
> > > >
> > > > > Commit cf9e55f494 ("submodule: prevent backslash expantion in
> > > > > submodule
> > > > > names", 07-04-2017) added a test which creates a git repository with
> > > > > some backslash characters in the name. This test cannot work on
> > > > > windows,
> > > > > since the backslash is used as the directory separator. In order to
> > > > > suppress this test on cygwin, MinGW and Git for Windows, we add the
> > > > > BSLASHPSPEC prerequisite. (see also commits 6fd1106aa4 and
> > > > > c51c0da222).
> > >
> > > First, let me say that meaning of BSLASHPSPEC was
> > > "keeps backslaches in pathspec arguments" originally,
> > > but it apparently changed meaning since then.
> >
> > Indeed. I started to give some of the history in the commit message, but
> > it was nearly 3am, so I punted with the 'see also commits 6fd1106aa4 and
> > c51c0da222' ... ;-)
> >
> > > t7400.20 does not fail for the MinGW port because the
> > > test case only operates on the file system, but never
> > > checks whether an entry 'sub\with\backslash' is present
> > > in the index.
> >
> > Ah, OK. I only looked at my (64-bit) MSYS2 build, which fails
> > exactly the same as cygwin. Hmm, wait, let me just rebuild on
> > MinGW64 ... indeed it passes (well it passes t7400.20, but it
> > fails on t7400.11, 61, 63, 87 and 89)!
>
> I don't observe these failures. Are you using a vanila MSYS2 environment?
Please note that the "vanilla MSYS2 environment" is *not* expected to pass
the test suite when compiling in MINGW mode. In fact, it is expected to
fail.
In 2015, I made a couple of changes to the MSYS2 runtime in preparation
for the big bump to Git for Windows 2.x (which switched from the old MSys
environment to the new MSYS2 environment), and released Git for Windows
2.5.0 with a heavily patched msys-2.0.dll. My hope was that those changes
would be welcome in the MSYS2 project, but well, they kinda weren't. So I
was forced to abandon my original plan to contribute all of those fixes to
"upstream MSYS2".
To see the changes I (and others) made:
https://github.com/git-for-windows/msys2-runtime/compare/master%5E%7B/Start.the.merging.rebase%7D...master
I even started collecting the exact tests that are failing with the
vanilla MSYS2 runtime vs Git for Windows' fork, when I still had hopes
that we could test things with AppVeyor (but the builds were already too
slow, we hit the timeout even before trying to run the tests, so I gave up
on that front):
REM MSYS2's runtime does not carry Git for Windows' tweaks yet, so these
tests cannot pass:
set GIT_SKIP_TESTS='t0003 t0006 t0024 t1100 t1400 t1402 t1501 t1504 t1506
t1508 t1513 t3001 t3070 t3200 t3301 t3400 t3404 t3513 t3703 t4116 t4150
t4208 t4211 t5000 t5001 t5002 t5004 t5500 t5601 t5602 t5603 t5801 t6006
t6018 t6041 t6130 t6132 t6300 t7201 t7400 t7501 t7502 t8002 t8006 t9001
t9350 t9700 t9903'
The reason I did this was to avoid having to spend time in the CI job to
replace the vanilla MSYS2 runtime with Git for Windows' forked one (and
AppVeyor offers a -- rarely updated -- version of MSYS2 in its build
agents out of the box).
I might have dug deeper in order to skip only specific test cases, but as
AppVeyor was already a dead end...
Ciao,
Dscho