Windows上的git责备报告"致命:HEAD中没有这样的路径<path>"

Question

当我对文件夹e,g中的文件运行git blame时:

git blame Foo/FileA.txt

它返回

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

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

我正在发布这个问题和答案,因为它让我今天难倒了一段时间,而且我找不到能够解决所有解决方案的单一答案.

Answer 1

这是因为重命名文件系统上的父文件夹,其新名称仅根据大小写而不同 - 并且在重命名文件夹之前的提交中添加了一些文件.这是来自Powershell提示的repro:

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(自文件夹重命名后将生成哪个选项卡完成)将失败,并且没有此类路径错误,而是git blame /Foo/FileB.txt甚至git blame /foo/FileA.txt会成功.

Futhermore,调用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开关来进行"假设"干运行,这样你就可以检查你的重命名是否正确):

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

以上用于git ls-files获取问题"foo"文件夹中的文件列表,将其管道化为"ForEach"(%是其中的快捷方式),然后git mv对提供原始名称($_)和新名称"F"的每个文件执行'和文件名的其余部分('F' + $_.Substring(1)))