git.exe拉错误：无法生成git：参数无效

Question

我的错误与图片完全一样。

尝试各种设置，Google搜索，重新安装。 Git pull在TortoiseGit中不起作用，但我可以提交并推送。

我在网络标签中有ss​​h客户端。我还能尝试什么？

Answer 1

<强>更新

Git for Windows 2.16.1（4）已经发布，应解决此问题：https://github.com/git-for-windows/git/releases

旧回答：

这是Git for Windows 2.16.1（2）和2.16.1（3）中的一个已知问题：https://github.com/git-for-windows/git/issues/1481

只有解决方法是使用Git for Windows 2.16.1（Download）（或更早版本; 2.16.0还有其他关键问题：TortoiseGit revert failed - unable to revert local changes）。

仅供注释，TortoiseGit中的bug报告：https://gitlab.com/tortoisegit/tortoisegit/issues/3156

PS：对于Windows的Git＆gt; = 2.16，您至少需要TortoiseGit 2.5.7（参见https://stackoverflow.com/a/48457419/3906760）。

Answer 2

我回滚到版本2.16.0，问题已经消失。 Git for Windows 2.16.0(2)

Answer 3

  

在网络标签

中安装ssh客户端

但您的远程repo URL是https://github.com/toouur/programming_test_repo，这是一个https网址，因此不涉及SSH。完全没有。

确保TortoiseGit的设置确实提到了git.exe的路径，而不是git.exe本身 例如：C:\Program Files\Git\bin，而非C:\Program Files\Git\bin\git.exe

您可以在任何地方引用未经压缩的latest Git for Windows，PortableGit-2.16.1.2-64-bit.7z.exe。

Answer 4

git-for-windows/git issue 1481在2018年针对Git 2.16进行了正式修订，并已随Git 2.25（2020年第一季度）修复。

针对以下问题引入了解决方法：生成子进程时FD处于打开状态，而FD在子进程中保持打开状态可能会干扰Windows上父进程的操作。

请参见commit 3ba3720（2019年12月2日），commit 4d0375c（2019年11月30日）和commit ac33519，commit 9a780a3，commit c5a03b1，commit eea4a7f （2019年11月22日）作者：Johannes Schindelin (dscho)。
^{（由Junio C Hamano -- gitster --在commit 55d607d中合并，2019年12月10日）}

  

mingw：解决不正确的标准手柄

     

^{签名人：Johannes Schindelin}

     

由于某种原因，当通过TortoiseGit调用标准句柄或至少由_get_osfhandle( 0返回的用于标准输入的东西时，可以采用（HANDLE）-2值（不合法）值，根据文档）。

     

即使未在任何地方记录此值，如果将CreateProcess()设置为该值，hStdInput似乎也可以正常工作。

     

相反，即将到来的代码来限制由生成的进程继承哪些文件句柄时，将此类句柄值包括在列表中将导致ERROR_INVALID_PARAMETER。

注意：

  

mingw：仅在Windows 7和更高版本上限制文件句柄继承

     

^{签名人：Johannes Schindelin}

     

事实证明，它在Vista上不能很好地工作，有关详细信息，请参见git-for-windows/git issue 1742 。

     

根据Old New Thing，它应该在Windows Vista和更高版本上可以工作。

     

但是，当涉及管道时，Windows Vista显然存在问题。鉴于Windows Vista已经过期（官方支持已于2017年4月11日终止），我们不要在这个问题上花费太多时间，而只是在更早的任何Windows版本上禁用文件句柄继承限制比Windows 7。   为了解决这个问题，请对_get_osfhandle()返回的值（HANDLE）-2进行特殊处理，并将其替换为INVALID_HANDLE_VALUE,，这将希望即使从TortoiseGit调用时，句柄继承限制也可以正常工作。

这就是为什么有new configuration setting的原因：

core.restrictinheritedhandles:

     

仅Windows：覆盖生成的进程仅继承标准文件句柄（stdin，stdout和stderr）还是所有句柄。
  可以是auto，true或false。默认值为auto，这意味着在Windows 7及更高版本上为true，在较早的Windows版本上为false。

---

  

mingw：生成的进程仅需要继承标准句柄

     

^{签名人：Johannes Schindelin}

     

默认情况下，除非CreateProcess()参数设置为bInheritHandles，否则TRUE不会继承任何打开的文件句柄。我们需要设置它，因为我们需要传入stdin / stdout / stderr与子进程进行对话。
  可悲的是，这意味着所有文件句柄（除非通过O_NOINHERIT标记）都被继承。

     

这会导致VFS for Git （用于Git的虚拟文件系统）中的问题，其中使用了长时间运行的读取对象挂钩来补充丢失的对象，具体取决于情况，可能仅在 Git打开文件句柄之后被称为。

     

理想情况下，除非确实需要 （例如，当我们希望将打开的文件句柄作为标准句柄传递到子进程中时），否则我们不会在没有O_NOINHERIT的情况下打开文件，但是显然是太容易引入不正确的open()调用：发生了这种情况，并且在启动读取对象挂钩之后阻止了文件的更新，因为挂钩仍然保留了该文件的句柄。

     

很高兴有一个解决方案：如“ Old New Thing”中所述，有一种方法可以从Windows Vista开始，让我们精确地定义子进程应继承哪些句柄。

     

并且由于我们将用于Git for Windows的最低Windows版本提高到v2.10.1的Vista版本（即很久以前是 ），因此可以使用此方法。因此，让我们做到这一点。

     

我们需要确保要继承的句柄列表不包含重复项；否则CreateProcessW()会失败，并显示ERROR_INVALID_ARGUMENT。

     

与此同时，请停止将errno设置为ENOENT，除非它确实是正确的值。

     

此外，在某些错误情况下（例如，在Windows 7上，您不应该限制句柄继承），这在您可以指定限制的句柄上要严格得多。

并且：

  

mingw：尝试限制句柄继承时，请正确设置errno

     

^{举报人：约翰内斯·西维特
  签名人：Johannes Schindelin
   Acked-by：约翰内斯·瑟维特（Johannes Sixt）}

     

在9a780a384de中（“ mingw：生成的进程仅需要继承标准句柄”，2019-11-22，Git v2.25.0-merge在{{3}中列出}），我们教Windows特定的部分来限制将哪些文件句柄传递给生成的进程。

     

由于该逻辑在Windows版本之间似乎有些脆弱（例如，我们在Windows的Git中仍然支持Windows Vista），因此添加了一个后备选项以尝试再次产生该过程，这次不限制生成的进程要继承哪些文件句柄。

     

在通常情况下（例如，由于文件句柄继承以外的其他原因而导致无法启动进程），回退尝试当然仍然会失败。

     

至关重要的是，我们在该代码路径中缺少的一件事是适当设置errno。

     

让我们通过确保正确设置errno来解决此问题。甚至以前似乎在错误的情况下设置了errno：CreateProcessW()成功时返回非零，但是errno仅被设置为非零情况。

     

但是，当mingw_spawnvpe()要查看所讨论的文件是否为脚本时，它将调用parse_interpreter()，而该文件又会尝试open()。显然，此调用失败，并将errno设置为ENOENT，从该测试帮助程序开始的调用链的深处。

     

相反，我们在函数errno的开头强制重置mingw_spawnve_fd()，鉴于该函数的调用者希望查看{ {1}}如果返回-1。如果errno为0（“无错误”），则将执行t0061.2之类的回归测试。