Git使用什么算法来确定某个文件是否已经重命名？
这是几分钟前git status生成的内容：
用黄色框标记的信息是不正确的。实际上并没有此类重命名。文件views/file/create.php和views/file/index.php在完全新的两个文件集合views/logo/create.php和views/logo/index.php被创建后的半个小时内被删除了。
这两个文件集合（对于Git而言）可能看起来相似，但事实是：这是一个完全新的文件集合，在半个小时之前在不同的目录中创建，与第一组文件被删除的时间相隔20分钟左右。
由于Git提供的信息是不正确的，我想满足我的好奇心，这就是我问的原因。
来自 维基百科:
重命名由隐式处理而不是显式处理。人们通常对CVS的抱怨是它使用文件名称来标识其修订历史记录，因此移动或重命名文件是不可能的，除非要么中断其历史记录，要么重命名历史记录，从而使历史记录不准确。大多数后CVS版本控制系统通过为文件分配一个唯一的长期名称（一种inode编号）来解决这个问题，该名称在重命名时保持不变。Git不记录这样的标识符，并且这被认为是一种优势。源代码文件有时会被拆分或合并，以及简单地重命名，将其记录为简单的重命名会导致对发生情况的不准确描述被固定在（不可变的）历史记录中。Git通过在浏览快照历史记录时检测重命名来解决此问题，而不是在创建快照时记录它。（简而言之，在版本N中给出文件时，版本N-1中同名文件是其默认祖先。但是，当版本N-1中没有同名文件时，Git会搜索仅存在于版本N-1中且与新文件非常相似的文件。）但是，这确实需要在每次查看历史记录时进行更多的CPU密集型工作，并且有许多选项可调整启发式算法。此机制并不总是奏效；有时会将带有相同提交中的更改的已重命名文件读取为旧文件的删除和新文件的创建。开发人员可以通过单独提交重命名和更改来解决此限制。
