Git如何知道该文件已重命名？ [复制]

Question

Git 使用什么算法来确定某个文件被重命名了？

这是 git status 几分钟前生成的：

用黄色框标记的信息不正确。实际上没有这样的重命名。文件 views/file/create.php 和 views/file/index.php 在创建一组全新的两个文件（views/logo/create.php 和 views/logo/index.php）半小时后被真正删除。

这两个文件集可能看起来（对 Git）非常相似，但事实仍然存在 - 它们不一样，重命名的文件。这是一组完整的新文件，在删除第一组文件前大约半小时在不同目录中创建。

由于 Git 提供的信息不正确，我想满足我的好奇心，这就是我问的原因。

Answer 1

来自Wikipedia：

重命名是隐式处理的，而不是显式处理的。普通的 对 CVS 的抱怨是它使用文件名来识别它的 修订历史，因此无法移动或重命名文件 要么中断其历史，要么重命名历史，从而 使历史不准确。大多数 CVS 后版本控制系统 通过给文件一个唯一的长寿命名称来解决这个问题（一种 inode 号）在重命名后仍然存在。 Git 不会记录这样的 标识符，这被认为是一个优势。 [34] [35]源代码 文件有时会被拆分或合并，以及简单地重命名，[36] 和 将此记录为简单的重命名会冻结不准确的 描述（不可变的）历史中发生的事情。 Git 地址 通过在浏览快照历史记录时检测重命名问题 而不是在制作快照时记录它。 [37] (简而言之，给定 版本 N 中的文件，版本 N-1 中的同名文件是其 默认祖先。但是，当没有同名文件时 修订版 N-1，Git 搜索仅存在于修订版中的文件 N-1 并且与新文件非常相似。）但是，它确实需要 每次查看历史记录时都会进行更多的 CPU 密集型工作，并且一些 调整启发式的选项。这种机制并不总是 工作;有时在同一次提交中更改了重命名的文件 被读取为删除旧文件并创建新文件。 开发人员可以通过提交重命名来解决此限制 并单独更改。