Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
run-command: refine Git LFS check on Windows 7 (#5059)
In commit 46d14a6 of PR #5042 the `wait_or_whine()` function in `run-command.c` was revised to [call](https://github.com/git-for-windows/git/blob/b105301ef9107c8c2980a24eca89a2992a1c074b/run-command.c#L571) a new function in the case where an executable fails to run, to check whether this was caused by a Git LFS binary compiled with a version of the Go language that no longer supports Windows 7. This change was made to address the issue reported in #4996. The new function, `win32_warn_about_git_lfs_on_windows7()`, [performs](https://github.com/git-for-windows/git/blob/b105301ef9107c8c2980a24eca89a2992a1c074b/compat/win32/path-utils.c#L226-L232) several initial checks to test whether the failed executable returned the exit code `0x0b00` and is named `git-lfs`, and whether we are running Windows 7 or not. Only if all these conditions are met does it then proceed to try to extract the Go language version from the binary file and check whether it is 1.21.0 or higher. However, these initial checks may not cover all possible use and failure cases. First, when running in Git Bash (in a Windows 7 SP1 virtual machine), the exit code seen from a recent Git LFS executable was `0x02`, so we also want to check for that value as well as `0x0b00`. Second, the name of the executable may not always be entirely lowercase, since it is possible to invoke Git LFS through Git by running, for example, `git LFS ls-files` (at least, on Windows, and with a case-insensitive filesystem). We therefore need to ignore case when checking the executable's name. And third, the name of the executable may not have a trailing space character, so we also need to check for the case where the name in `argv0` is simply `git-lfs`. With these changes, we can more reliably detect a failure of the Git LFS executable in a wider range of circumstances.
- Loading branch information