github/git Checkout 在 Windows 上返回“错误：无效路径”

Question

当我尝试从 github 签出存储库时，出现错误：

error: invalid path 'configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.03-1.el6.noarch.rpm'

我怀疑问题是路径包含一个 : 这在 Windows 上是非法的。

在研究错误后，我找到了 2 个可能的答案：
1) 更改存储库文件上的路径。 不幸的是，这是团队资源，在可预见的未来无法修复。
2）使用稀疏结帐。 我已经尝试过没有效果，如下所示：

$ git clone -n​​ git@github.com:XXXXXX/deploy.git
克隆到 'deploy'...
远程：枚举对象：57，完成。
远程：计数对象：100% (57/57)，完成。
远程：压缩对象：100% (49/49)，完成。
远程：总计 86457 (delta 10)，重用 22 (delta 8)，打包重用 86400
接收对象：100% (86457/86457)，1.50 GiB | 4.73 MiB/s，完成。
解析增量：100% (59779/59779)，完成。
$ cd deploy/
$ git config core.sparsecheckout true
$ echo www >> .git/info/sparse-checkout
$ git checkout centos6
错误：路径无效'configs/perl-modules/DIST.64/perl-HTML-Tree-1 :5.03-1.el6.noarch.rpm'
错误：无效路径 'configs/perlbrew/perls/perl-5.24.1/man/man3/App::Cpan.3'
。
. （对许多文件重复）
。

这是使用 Git for Windows“git version 2.28.0.windows.1”完成的。我还尝试了两种类型的行尾并使用各种版本的 .git/info/sparse-checkout 例如：

/*
!/configs/perl-modules
!/configs/perlbrew/perls/perl-5.24.1/man/man3

Checkout 在 Linux、MacOS 和 WSL 上运行良好，唯一的问题是我的 IDE 在那里不起作用。为什么 sparse-checkout 在 Windows 上不起作用。还有其他可能吗？

Answer 1

我也遇到过类似的问题，尝试在 Windows 上从 GitHub 检出一个存储库，其中包含名称中带有“ : ”的文件。（导致问题的示例文件名：“ test-img.jpg:Zone.Identifier ”）。存储库已下载，但文件未显示在文件夹中。

我发现运行git config core.protectNTFS false解决了我的问题，但前提是我在运行之前和之后采取了一些步骤。整个过程是这样的：

1. 将 Git 存储库克隆到本地；
2. 'cd' 进入刚刚克隆的本地 Git 存储库文件夹；
3. 跑步git reset
4. 跑步git config core.protectNTFS false
5. 运行git checkout（只需 git checkout，命令末尾没有 *）。

之后，我就可以看到这些文件了。诚然，从 Git 下载的一些额外内容通常会被省略，但对我来说这并不是什么大问题。

Answer 2

在 git-for-windows 错误跟踪器 ( https://github.com/git-for-windows/git/issues/2803 )上打开一个问题后，我发现我的问题已经提交为https:// github.com/git-for-windows/git/issues/2777。该问题表明我需要设置另一个 git 标志：

git config core.protectNTFS false

这 (#2777) 确实包含对我的问题的绕过。我希望 git 或 git-for-windows（响应迅速）提出更好的警告消息，甚至像文件路径映射方案这样的真正修复。

请注意，这只是在 Windows 中使用 sparse-checkout 时的问题。

Answer 3

对于那些只需要命令来解决问题的人：

git clone --sparse -c core.protectNTFS=false -n <repo-URL>
git sparse-checkout add "\!<pattern1>" "\!<pattern2>"
git checkout <branch>

模式与存储库根相关，可以使用*

Answer 4

我怀疑问题是路径包含 [冒号字符]，:这在 Windows 上是非法的。

这实际上就是问题所在。

[稀疏结账]!configs/perlbrew/perls/perl-5.24.1/man/man3

这里被抱怨的路径名是：

configs/perl-modules/DIST.64/perl-HTML-Tree-1:5.03-1.el6.noarch.rpm

它不以 开头configs/perlbrew/，更不用说完整的要跳过的路径。

您可以通过（痛苦地）枚举所有无效文件名来解决此问题。不过，Git 需要一个更好的通用机制来实现这一点。

Answer 5

附录 - git 版本 2.34.1.windows.1 及其他（？）

\n

遗憾的是，git config core.protectNTFS false结果还不够；带有冒号的文件名的内容会丢失 (filesize = 0)。

\n

解决方案

\n

长话短说

\n

git diff ec28c8ddd5f8c83d11604bcae69afb46d79b1029 > p.patch\npatch -R -f -i p.patch\ngit add *\ngit commit \n

\n

阐述

\n

事实证明git config core.protectNTFS false确实有效，只要不再产生致命错误git checkout即可。

\n

但是，git 现在将生成剪切到冒号且内容为零的文件名。

\n

例如Writing-Bops:-The-Bebop-Schema-Language.md(~9KB) --> Writing-Bops(0 KB)

\n

为了解决这个问题，我们需要以另一种方式获取原始有问题文件内容的副本，以便我们可以恢复它。

\n

\n

条件/假设

\n

\n
• 这假设您由于某种原因不能或不会使用稀疏克隆。
\n
• git apply-filter当您跟踪第三方 git 存储库时，同样可以使用其他“永久重写”git 历史记录的技术。
\n
• 您正在运行 Windows，使用 NTFS 存储、git-for-windows 作为bash您的 shell，并且有一个patch.exe可用的（patch --version应该​​报告类似“GNU patch 2.7.6”的内容）
\n

\n

\n

（在我们的例子中，我们正在处理 github wiki 克隆，并遇到了包含冒号的文件名问题。当然，我们希望就地修复此问题，而不需要额外的“稀疏克隆”或 WSL 里程。）

\n

结果我们可以得到丢失的内容

\n

git config core.protectNTFS false\ngit checkout <hash>\n

\n

通过跑步patch。（顺便说一句：如果您尝试比较/比较这些提交， TortoiseGit 将永远挂起！）

\n

使用下一个命令获取包含所有缺失更改的补丁文件。如果您有多个带有冒号或其他问题的文件，则所有缺失的内容将在补丁文件中列出：一个补丁文件即可捕获所有内容！

\n

git diff ec28c8ddd5f8c83d11604bcae69afb46d79b1029 > p.patch\n# ^^^^ reference the git hash with the offending original file(s)\n

\n

现在您已经有了补丁文件，您可以将其应用到当前工作目录：必须反向应用它（-R）：

\n

patch -R -f -i p.patch\n

\n

如果你忘记了-R，补丁会询问（回答[y]es）；如果你确实指定了-Rpatch 将会更加困难，所以-f( force ) 是为了关闭 patch 并完成工作。

\n

这应该列出一个或多个被修补的文件，例如

\n

$ patch -R -f -i p.patch\npatching file Writing-Bops:-The-Bebop-Schema-Language.md\n

\n

\n

注意该文件名中的冒号：原来 Windows 上的 GNU 补丁（至少 v2.7.6）使用Unicode 同形文字来模拟文件名中的冒号。另请参阅下文。

\n

\n

现在，您的工作目录中已包含冒号文件的原始内容，您现在可以将这些文件添加到 git 索引并照常提交它们：

\n

\n

警告：在继续之前，您可能需要清理（删除）先前生成的空剪辑git checkout文件名！

\n

\n

\n

注意：如果您不喜欢patch -i分配给缺失内容的同形文件名，您可以在提交结果之前将其更改为您喜欢的任何内容。

\n

\n

git add *\ngit commit \n

\n

验证结果

\n

当您正确执行所有操作时，最后一次提交应列出重命名的冒号文件，因为您没有更改内容，因此git commit应该按原样检测到“文件重命名操作”。

\n

额外：用同形文字替换冒号

\n

我发现了几个看起来或多或少像冒号的 Unicode 同形文字，但在 NTFS 文件名中被认为是合法的。

\n

经过一番实验后，我决定使用它，因为我想尽可能\xea\x9e\x89保持我正在摆弄的 github wiki 页面完好无损。

\n

一般来说，我会完全丢弃冒号，或者用一个或多个连字符替换它，但对于 wiki MarkDown 页面，该决定可以采用另一种方式。

\n

Answer 6

In our case there was a filename aux.go and windows doesn't allow the creation of a file that has the word aux

Read more about this issue here

Answer 7

我发现了一个没有提到的选项。使用WSL签出文件。

git clone我在 WSL/Bash 而不是 PowerShell/CMD 中运行。WSL 透明地处理修复文件名，即使它们仍然存储在 NTFS 上并且我使用 VS Code for Windows 打开它们。我能够在 Windows 中修改文件，甚至可以在 Windows 上推送我的更改。

Answer 8

在GitHub中：转到 Repo URL ( https://github.com/UserNameHere/RepoNameHere )，然后单击“代码”>“下载 ZIP”，然后在 Windows 中提取 .zip 文件对我来说是成功的（我必须跳过无效文件）