Question

当我对文件夹e，g，：

中的文件运行git blame时

git blame Foo/FileA.txt

它返回

fatal: no such path 'Foo/FileA.txt' in HEAD

我可以清楚地看到文件系统中存在此文件，并且可以成功归咎于同一文件夹中的其他文件 - 所以发生了什么？

我发布了这个问题和答案，因为它让我今天难倒了一段时间，而且我无法找到能够解决所有问题的单一答案。

Answer 1

这是因为重命名文件系统上的父文件夹，其新名称仅因大小写而异 - 并且在重命名文件夹之前的提交中添加了一些文件。这是一个复仇者，来自Powershell提示：

mkdir C:\RenameProblem
cd C:\RenameProblem
git init
mkdir foo
"FileA" > foo/FileA.txt
git add foo/FileA.txt
git commit -m "Add FileA"

然后在Windows资源管理器中，重命名目录＆＃34; foo＆＃34;到＆＃34; Foo＆＃34;然后继续使用Powershell：

"FileB" > Foo/FileB.txt
git add Foo/FileB.txt
git commit -m "Add FileB"

此时，git blame /Foo/FileA.txt（自文件夹重命名后将生成哪个标签页）将失败，并且没有此类路径错误，而git blame /Foo/FileB.txt甚至git blame /foo/FileA.txt将成功。< / p>

此外，对git ls-files Foo的来电仅会列出FileB.txt而git ls-files foo只会列出FileA.txt。不是一个在Windows上的好地方。

就我而言，我在文件夹名称的两个版本之间分配了大量文件。

您可以通过使用git mv重命名文件来解决此问题：

git mv foo/FileA.txt Foo/FileA.txt
git commit -am "Rename foo to Foo"

如果你需要重命名很多文件，请使用一些Powershell（另请注意git mv有一个-n切换来执行＆＃34;假设＆＃34;干运行，所以你可以检查你的重命名是否正确）：

git ls-files foo | % { (& git mv $_ $('F' + $_.Substring(1))) }

以上使用git ls-files来获取问题中的文件列表＆＃34; foo＆＃34;文件夹，将其传输到＆＃34; ForEach＆＃34; （%是该快捷方式），然后为每个提供原始名称（git mv）和新名称＆＃39; F＆＃39;的文件执行$_。和文件名的其余部分（'F' + $_.Substring(1))）

Answer 2

另一种可能性是文件或包含目录是符号链接。您可以使用ls -l来验证这种情况。尝试将文件归咎于其原始位置。

Answer 3

从文件目录输入终端，然后指责终端应该可以。

git责备Windows报告＆＃34;致命：HEAD＆＃34;

3 个答案: