git - git blame on windows 报告“致命：没有这样的路径在头部”

Question

当我对文件夹中的文件运行 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 资源管理器中，将目录“foo”重命名为“Foo”，然后在 Powershell 中继续：

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

此时，git blame /Foo/FileA.txt（由于文件夹已重命名，将生成哪个选项卡完成）将失败，并出现 no such path 错误，而git blame /Foo/FileB.txt甚至git blame /foo/FileA.txt会成功。

此外，调用git ls-files Foowill list onlyFileB.txt和git ls-files foowill list only FileA.txt。在 Windows 上不是一个好地方。

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

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

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

如果您需要重命名大量文件，请使用一些 Powershell（另外，请注意，它git mv有一个-n开关可以进行“假设”试运行，因此您可以检查您的重命名是否正确）：

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

上面用于git ls-files获取问题“foo”文件夹中的文件列表，将其通过管道传输到“ForEach”（%是它的快捷方式），然后git mv为每个提供原始名称（$_）和新名称“F”的文件执行' 和文件名的其余部分 ( 'F' + $_.Substring(1)))

Answer 2

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

Answer 3

从文件目录进入终端，然后指责它应该可以工作。