Git如何知道该文件已重命名？ [英] How does Git know that file was renamed?
问题描述
标有黄色框的信息不正确。实际上没有这种重新命名。文件 views / file / create.php 和 views / file / index.php 新创建了两个文件 - views / logo / create.php 和 views / logo / index.php 已创建。
这两个文件集可能看起来（对于Git）非常相似，但事实仍然存在 - 这些不一样，重命名文件。这是一个完整的新文件集，在删除第一组文件前半小时在不同的目录中创建。
由于Git提供的信息不正确，我会喜欢提供我的好奇心，这就是为什么我问。
重命名是隐式处理的比明确。对CVS的一个常见的
投诉是它使用一个文件的名字来标识它的
修订历史，所以如果没有
或者中断它的历史或者重命名文件，移动或者重命名一个文件是不可能的历史，从而
使历史不准确。大多数CVS后修订控制系统
通过为文件提供一个独特的长命名（一种inode
数字）来解决这个问题。 Git没有记录这样的
标识符，这被认为是一个优势。[34] [35]源代码
文件有时会被拆分或合并以及重命名，[36]和
将其记录为简单的重命名将冻结关于（不可变）历史中发生的事情的不准确的
描述。 Git通过在浏览快照历史记录
时检测重命名而不是在创建快照时记录它来解决
问题[37]。 （简单地说，如果给定版本N中的
a文件，修订版N-1中的同名文件就是它的
默认祖先，但是当$ b $中没有类似命名的文件时b版本N-1，Git搜索只存在于修订版
N-1中的文件，并且与新文件非常相似。）但是，它确实需要
更多的CPU密集每次检查历史时都会工作，并且可以调整
的选项来调整启发式。这个机制并不总是
的工作;有时会使用同一提交
中的更改重命名的文件被读取为旧文件的删除和新文件的创建。
开发人员可以通过提交重命名
并单独更改来解决此限制。
What algorithm Git uses to determine, that some file was renamed?
This is, what git status produced just a few minutes before:
Information marked with yellow box is incorrect. There was actually no such kind of rename. Files views/file/create.php and views/file/index.php were truly deleted half hour after a completely new set of two files -- views/logo/create.php and views/logo/index.php was created.
Both files sets may seem (to Git) quite similar, but the fact remains -- these are not the same, renamed files. This is a complete new set of files, created in different directory about half an hour before deleting first set of files.
Since information provided by Git is incorrect, I'd like to feed my curiosity and that's why I'm asking.
From Wikipedia:
Renames are handled implicitly rather than explicitly. A common complaint with CVS is that it uses the name of a file to identify its revision history, so moving or renaming a file is not possible without either interrupting its history, or renaming the history and thereby making the history inaccurate. Most post-CVS revision control systems solve this by giving a file a unique long-lived name (a sort of inode number) that survives renaming. Git does not record such an identifier, and this is claimed as an advantage.[34][35] Source code files are sometimes split or merged as well as simply renamed,[36] and recording this as a simple rename would freeze an inaccurate description of what happened in the (immutable) history. Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot.[37] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor. However, when there is no like-named file in revision N−1, Git searches for a file that existed only in revision N−1 and is very similar to the new file.) However, it does require more CPU-intensive work every time history is reviewed, and a number of options to adjust the heuristics. This mechanism does not always work; sometimes a file that is renamed with changes in the same commit is read as a deletion of the old file and the creation of a new file. Developers can work around this limitation by committing the rename and changes separately.
这篇关于Git如何知道该文件已重命名？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
