git.exe pull error: cannot spawn git: Invalid argument
git.exe pull error: cannot spawn git: Invalid argument
我有一个错误，与图片上的完全一样。
尝试了各种设置，用谷歌搜索，然后重新安装。 Git拉在 Tortoise 中不起作用Git，不过我可以提交和推送。
我在网络选项卡中有 ssh 客户端。我还能尝试什么？
我回滚到2.16.0版本，问题消失了。 Git for Windows 2.16.0(2)
更新：
Git for Windows 2.16.1(4) 已出，应该可以解决此问题：https://github.com/git-for-windows/git/releases
旧答案：
这是 Git 中 Windows 2.16.1(2) 和 2.16.1(3) 的已知问题：https://github.com/git-for-windows/git/issues/1481
唯一的解决方法是对 Windows 2.16.1 (Download) (or older; 2.16.0 has other critical issues: ).
使用 Git
仅供参考，Tortoise 中的错误报告Git：https://gitlab.com/tortoisegit/tortoisegit/issues/3156
PS: For Git for Windows >= 2.16 你至少需要 TortoiseGit 2.5.7 (cf. ).
git-for-windows/git issue 1481 在 2018 年提到的 Git 2.16 正式固定为 Git 2.25（2020 年第一季度）。
针对 Windows 上的 FD 在生成子进程时保持打开状态并在子进程中保持打开状态可能会干扰父进程中的操作的问题引入了解决方法。
参见 commit 3ba3720 (02 Dec 2019), commit 4d0375c (30 Nov 2019), and commit ac33519, commit 9a780a3, commit c5a03b1, commit eea4a7f (22 Nov 2019) by Johannes Schindelin (dscho)。
（由 Junio C Hamano -- gitster -- in commit 55d607d 合并，2019 年 12 月 10 日）
mingw: work around incorrect standard handles
Signed-off-by: Johannes Schindelin
For some reason, when being called via TortoiseGit the standard handles, or at least what is returned by _get_osfhandle(0) for standard input, can take on the value (HANDLE)-2 (which is not a legal value, according to the documentation).
Even if this value is not documented anywhere, CreateProcess() seems to work fine without complaints if hStdInput set to this value.
In contrast, the upcoming code to restrict which file handles get inherited by spawned processes would result in ERROR_INVALID_PARAMETER when including such handle values in the list.
注：
mingw: restrict file handle inheritance only on Windows 7 and later
Signed-off-by: Johannes Schindelin
Turns out that it don't work so well on Vista, see git-for-windows/git issue 1742 for details.
According to Old New Thing, it should work on Windows Vista and later.
But apparently there are issues on Windows Vista when pipes are involved. Given that Windows Vista is past its end of life (official support ended on April 11th, 2017), let's not spend too much time on this issue and just disable the file handle inheritance restriction on any Windows version earlier than Windows 7.
To help this, special-case the value (HANDLE)-2 returned by _get_osfhandle() and replace it with INVALID_HANDLE_VALUE, which will hopefully let the handle inheritance restriction work even when called from TortoiseGit.
这就是为什么有一个 new configuration setting:
core.restrictinheritedhandles:
Windows-only: override whether spawned processes inherit only standard file handles (stdin, stdout and stderr) or all handles.
Can be auto, true or false. Defaults to auto, which means true on Windows 7 and later, and false on older Windows versions.
mingw: spawned processes need to inherit only standard handles
Signed-off-by: Johannes Schindelin
By default, CreateProcess() does not inherit any open file handles, unless the bInheritHandles parameter is set to TRUE. Which we do need to set because we need to pass in stdin/stdout/stderr to talk to the child processes.
Sadly, this means that all file handles (unless marked via O_NOINHERIT) are inherited.
This lead to problems in VFS for Git (the Virtual File System for Git), where a long-running read-object hook is used to hydrate missing objects, and depending on the circumstances, might only be called after Git opened a file handle.
Ideally, we would not open files without O_NOINHERIT unless really necessary (i.e. when we want to pass the opened file handle as standard handle into a child process), but apparently it is all-too-easy to introduce incorrect open() calls: this happened, and prevented updating a file after the read-object hook was started because the hook still held a handle on said file.
Happily, there is a solution: as described in the "Old New Thing" there is a way, starting with Windows Vista, that lets us define precisely which handles should be inherited by the child process.
And since we bumped the minimum Windows version for use with Git for Windows to Vista with v2.10.1 (i.e. a long time ago), we can use this method. So let's do exactly that.
We need to make sure that the list of handles to inherit does not contain duplicates; Otherwise CreateProcessW() would fail with ERROR_INVALID_ARGUMENT.
While at it, stop setting errno to ENOENT unless it really is the correct value.
Also, fall back to not limiting handle inheritance under certain error conditions (e.g. on Windows 7, which is a lot stricter in what handles you can specify to limit to).
并且：
mingw: do set errno correctly when trying to restrict handle inheritance
Reported-by: Johannes Sixt
Signed-off-by: Johannes Schindelin
Acked-by: Johannes Sixt
In 9a780a384de ("mingw: spawned processes need to inherit only standard handles", 2019-11-22, Git v2.25.0 -- merge listed in batch #5), we taught the Windows-specific part to restrict which file handles are passed on to the spawned processes.
Since this logic seemed to be a bit fragile across Windows versions (we still support Windows Vista in Git for Windows, for example), a fall-back was added to try spawning the process again, this time without restricting which file handles are to be inherited by the spawned process.
In the common case (i.e. when the process could not be spawned for reasons other than the file handle inheritance), the fall-back attempt would still fail, of course.
Crucially, one thing we missed in that code path was to set errno appropriately.
Let's fix that by making sure that errno is set correctly. It even appears that errno was set in the wrong case previously: CreateProcessW() returns non-zero upon success, but errno was set only in the non-zero case.
However, when mingw_spawnvpe() wants to see whether the file in question is a script, it calls parse_interpreter(), which in turn tries to open() the file. Obviously, this call fails, and sets errno to ENOENT, deep inside the call chain started from that test helper.
Instead, we force re-set errno at the beginning of the function mingw_spawnve_fd(), which should be safe given that callers of that function will want to look at errno if -1 was returned. And if that errno is 0 ("No error"), regression tests like t0061.2 will kick in.
我有一个错误，与图片上的完全一样。
尝试了各种设置，用谷歌搜索，然后重新安装。 Git拉在 Tortoise 中不起作用Git，不过我可以提交和推送。
我在网络选项卡中有 ssh 客户端。我还能尝试什么？
我回滚到2.16.0版本，问题消失了。 Git for Windows 2.16.0(2)
更新：
Git for Windows 2.16.1(4) 已出，应该可以解决此问题：https://github.com/git-for-windows/git/releases
旧答案：
这是 Git 中 Windows 2.16.1(2) 和 2.16.1(3) 的已知问题：https://github.com/git-for-windows/git/issues/1481
唯一的解决方法是对 Windows 2.16.1 (Download) (or older; 2.16.0 has other critical issues:
仅供参考，Tortoise 中的错误报告Git：https://gitlab.com/tortoisegit/tortoisegit/issues/3156
PS: For Git for Windows >= 2.16 你至少需要 TortoiseGit 2.5.7 (cf.
git-for-windows/git issue 1481 在 2018 年提到的 Git 2.16 正式固定为 Git 2.25（2020 年第一季度）。
针对 Windows 上的 FD 在生成子进程时保持打开状态并在子进程中保持打开状态可能会干扰父进程中的操作的问题引入了解决方法。
参见 commit 3ba3720 (02 Dec 2019), commit 4d0375c (30 Nov 2019), and commit ac33519, commit 9a780a3, commit c5a03b1, commit eea4a7f (22 Nov 2019) by Johannes Schindelin (dscho)。
（由 Junio C Hamano -- gitster -- in commit 55d607d 合并，2019 年 12 月 10 日）
mingw: work around incorrect standard handlesSigned-off-by: Johannes Schindelin
For some reason, when being called via TortoiseGit the standard handles, or at least what is returned by
_get_osfhandle(0) for standard input, can take on the value (HANDLE)-2 (which is not a legal value, according to the documentation).Even if this value is not documented anywhere,
CreateProcess()seems to work fine without complaints ifhStdInputset to this value.In contrast, the upcoming code to restrict which file handles get inherited by spawned processes would result in
ERROR_INVALID_PARAMETERwhen including such handle values in the list.
注：
mingw: restrict file handle inheritance only on Windows 7 and laterSigned-off-by: Johannes Schindelin
Turns out that it don't work so well on Vista, see
git-for-windows/gitissue 1742 for details.According to Old New Thing, it should work on Windows Vista and later.
But apparently there are issues on Windows Vista when pipes are involved. Given that Windows Vista is past its end of life (official support ended on April 11th, 2017), let's not spend too much time on this issue and just disable the file handle inheritance restriction on any Windows version earlier than Windows 7. To help this, special-case the value (HANDLE)-2 returned by
_get_osfhandle()and replace it withINVALID_HANDLE_VALUE,which will hopefully let the handle inheritance restriction work even when called from TortoiseGit.
这就是为什么有一个 new configuration setting:
core.restrictinheritedhandles:Windows-only: override whether spawned processes inherit only standard file handles (
stdin,stdoutandstderr) or all handles.
Can beauto,trueorfalse. Defaults toauto, which meanstrueon Windows 7 and later, andfalseon older Windows versions.
mingw: spawned processes need to inherit only standard handlesSigned-off-by: Johannes Schindelin
By default,
CreateProcess()does not inherit any open file handles, unless thebInheritHandlesparameter is set toTRUE. Which we do need to set because we need to pass in stdin/stdout/stderr to talk to the child processes.
Sadly, this means that all file handles (unless marked viaO_NOINHERIT) are inherited.This lead to problems in VFS for Git (the Virtual File System for Git), where a long-running read-object hook is used to hydrate missing objects, and depending on the circumstances, might only be called after Git opened a file handle.
Ideally, we would not open files without
O_NOINHERITunless really necessary (i.e. when we want to pass the opened file handle as standard handle into a child process), but apparently it is all-too-easy to introduce incorrectopen()calls: this happened, and prevented updating a file after the read-object hook was started because the hook still held a handle on said file.Happily, there is a solution: as described in the "Old New Thing" there is a way, starting with Windows Vista, that lets us define precisely which handles should be inherited by the child process.
And since we bumped the minimum Windows version for use with Git for Windows to Vista with v2.10.1 (i.e. a long time ago), we can use this method. So let's do exactly that.
We need to make sure that the list of handles to inherit does not contain duplicates; Otherwise
CreateProcessW()would fail withERROR_INVALID_ARGUMENT.While at it, stop setting
errnotoENOENTunless it really is the correct value.Also, fall back to not limiting handle inheritance under certain error conditions (e.g. on Windows 7, which is a lot stricter in what handles you can specify to limit to).
并且：
mingw: do seterrnocorrectly when trying to restrict handle inheritanceReported-by: Johannes Sixt
Signed-off-by: Johannes Schindelin
Acked-by: Johannes SixtIn 9a780a384de ("
mingw: spawned processes need to inherit only standard handles", 2019-11-22, Git v2.25.0 -- merge listed in batch #5), we taught the Windows-specific part to restrict which file handles are passed on to the spawned processes.Since this logic seemed to be a bit fragile across Windows versions (we still support Windows Vista in Git for Windows, for example), a fall-back was added to try spawning the process again, this time without restricting which file handles are to be inherited by the spawned process.
In the common case (i.e. when the process could not be spawned for reasons other than the file handle inheritance), the fall-back attempt would still fail, of course.
Crucially, one thing we missed in that code path was to set
errnoappropriately.Let's fix that by making sure that
errnois set correctly. It even appears thaterrnowas set in the wrong case previously:CreateProcessW()returns non-zero upon success, buterrnowas set only in the non-zero case.However, when
mingw_spawnvpe()wants to see whether the file in question is a script, it callsparse_interpreter(), which in turn tries toopen()the file. Obviously, this call fails, and setserrnotoENOENT, deep inside the call chain started from that test helper.Instead, we force re-set
errnoat the beginning of the functionmingw_spawnve_fd(), which should be safe given that callers of that function will want to look aterrnoif -1 was returned. And if thaterrnois 0 ("No error"), regression tests like t0061.2 will kick in.