Missing support for ISO 8601 date formats

[GisoBartels]

The following command fails, but works fine on git for Linux and MacOS

$ git show -s --format=%cd --date=format:‘%g.%V’ HEAD
fatal: invalid strftime format: '‘%g.%V’'

$ date +%g.%V
20.05

$ git --version
git version 2.25.0.windows.1

I found a potentially related issue here:
https://stackoverflow.com/questions/42568215/iso-8601-week-number-in-c

Cause could be an outdated MSVCRT.

[rimrul]

Could you test link with -lucrtbase? That works around it according to MinGW-w64 issue 793

[dscho]

link with -lucrtbase?

I guess that would break support for Windows Vista and for Windows 7, though, right?

[rimrul]

Should still work with Vista SP2/ 7 SP1/8 if they have update 2999226, according to Microsoft.

[dscho]

Should still work with Vista SP2/ 7 SP1/8 if they have update 2999226, according to Microsoft.

I don't think that would be easy. You cannot just link to two different MSVC runtimes at the same time. And for compatibility, we have to keep linking to the MSVC runtime that GCC links to.

What might be possible is to use LoadLibrary() to load ucrtbase and then GetProcAddress() to load the function and use it if available, similar to what we do in compat/win32/lazyload.h (we might even use those DECLARE_PROC_ADDR()/INIT_PROC_ADDR() macros, using a file-local variable to keep a copy of the old strftime() just in case we have to fall back to it if we cannot load the new one.

@rimrul wanna give it a try?

[dscho]

@rimrul wanna give it a try?

(I would have asked @GisoBartels but they seem to be most prolific with Java/Kotlin, not with C.)

[GisoBartels]

Exactly, thanks. Currently I don't even have a C development environment set up.

[rimrul]

I can certainly try. I'm a little bisy until about halfway through february, so it'll probably happen after that.

[dscho]

Currently I don't even have a C development environment set up.

That's easily fixed, though: download and install the Git for Windows SDK. After that, a Git SDK Bash will pop up and you can build Git via sdk build git.

So if you want to take your fate in your own hands, that'll be easy.

[rimrul]

Ok, I have a working prototype, but apparently t0014.4 is currently broken, even on master. There's some rouge line

run-command.c:662 trace: run_command: 'F:\git-sdk-32\mingw32\bin\busybox.exe' --help

in the output of GIT_TRACE=1 git frotz a "" b " " c. I definitely didn't introduce any busybox calls.

The test suite on the 32 bit SDK is really slow for me. t2016 alone is taking over 60 minutes on actual hardware. I dread running it on the vm that I set up for testing without ucrtbase.dll, but I guess it has to pass both with and without that.

Can I run make test with parallel jobs?

[dscho]

There's some rouge line

run-command.c:662 trace: run_command: 'F:\git-sdk-32\mingw32\bin\busybox.exe' --help

in the output of GIT_TRACE=1 git frotz a "" b " " c. I definitely didn't introduce any busybox calls.

This is Git for Windows trying to figure out whether BusyBox can serve a command that was not found on the PATH: see e41c1e6 for details.

The test suite on the 32 bit SDK is really slow for me. t2016 alone is taking over 60 minutes on actual hardware. I dread running it on the vm that I set up for testing without ucrtbase.dll, but I guess it has to pass both with and without that.

Typically, the reason for that is Windows Defender. I always add exclusions in my test setups.

Can I run make test with parallel jobs?

Yes, absolutely! I frequently run it with make -C t -j$(nproc). We do the something similar in our CI/PR builds, although we use prove, see https://github.com/git-for-windows/git/blob/v2.25.0.windows.1/ci/lib.sh#L134.

[rimrul]

Would it make sense to either add an exception to that busybox code for git commands (because I don't think they'd ship such a command) or alternatively teach t0014 about the possibility of busybox showing up in the trace output?

[dscho]

Would it make sense to either add an exception to that busybox code for git commands

The way I read the code, it should only spawn busybox --help if we try to launch a program that does not exist in the PATH. But git.exe is in the PATH, so either we're looking at a completely different program, or there is a bug in the code. Which one is it?

[rimrul]

We're looking for a dashed git command that (intentionally) does not exist. git-frotz.exe

[dscho]

Ah! Then yes, the busybox --help call here is totally inappropriate. We should probably enhance the "is this not in PATH" check by "does it not start with git-".