问题描述
显然，当您将一个函数从一个源代码文件移动到另一个源代码文件时，git 修订日志(对于新文件)可以向您显示该代码片段最初来自何处(例如参见 本教程).
Apparently, when you move a function from one source code file to another, the git revision log (for the new file) can show you where that code fragment was originally coming from (see for example the Viewing History section in this tutorial).
这是如何工作的?
推荐答案
它不跟踪它们.这就是它的美妙之处.
It doesn't track them. That's the beauty of it.
Git 只记录整个项目树的快照:这是提交之前所有文件的样子，这是提交之后的样子.我们是如何从这里走到那里的，Git 不在乎.
Git only records snapshots of the entire project tree: here's what all files looked like before the commit and here's how they look like after. How we got from here to there, Git doesn't care.
这允许在提交已经发生后编写智能工具，以从该提交中提取信息.例如，Git 中的重命名检测是通过将所有已删除文件与所有新文件进行比较并比较成对相似性度量来完成的.如果相似度度量大于 x，它们被认为是重命名的，如果它在 y 和 x 之间(y )，则认为是rename+edit，如果低于y，则认为是独立的.很酷的事情是，作为承诺考古学家"，您可以事后指定 x 和 y 应该是什么.如果提交只是记录这个文件是那个文件的重命名"，这将不起作用.
This allows intelligent tools to be written after a commit has already happened, to extract information from that commit. For example, rename detection in Git is done by comparing all deleted files against all new files and comparing pairwise similarity metrics. If the similarity metric is greater than x, they are considered renamed, if it is between y and x (y < x), it is considered to be a rename+edit, and if it is below y, they are considered independent. The cool thing is that you, as a "commit archaeologist", can specify after the fact, what x and y should be. This would not work if the commit simply recorded "this file is a rename of that file".
检测移动内容的工作原理类似:您将每个文件切成小块，计算所有切片之间的相似性度量，然后可以推断出这里删除的切片和添加到那里的非常相似的切片实际上是相同的切片从这里搬到那里.
Detecting moved content works similar: you slice every file into pieces, compute similarity metrics between all the slices and can then deduce that this slice which was deleted over here and this very similar slice which was added over there are actually the same slice that was moved from here to there.
然而，正如 tonfa 在他的回答中提到的，这非常昂贵，所以通常不会这样做.但它可以完成，这就是重点.
However, as tonfa mentioned in his answer, this is very expensive, so it is not normally done. But it could be done, and that's the point.
顺便说一句:这与 Google Wave、EtherPad、Gobby、SubEthaEdit、ACE 和 Co. 使用的 Operational Transformation 模型几乎完全相反.
BTW: this is pretty much the exact opposite of the Operational Transformation model used by Google Wave, EtherPad, Gobby, SubEthaEdit, ACE and Co.
这篇关于git 如何跟踪在文件之间移动的源代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！