git如何跟踪文件之间的源代码? [英] How does git track source code moved between files?

查看:170
本文介绍了git如何跟踪文件之间的源代码?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

显然,当你将一个函数从一个源代码文件移动到另一个源代码文件时,git修订日志(用于新文件)可以显示代码片段最初来自哪里(例如,参见本教程)。



这项工作?

解决方案

它不会跟踪它们。这是它的美丽。



Git只记录整个项目树的快照:以下是提交之前所有文件的样子,以下是他们看起来像后。 我们从这里到达那里,Git不关心。



这允许智能工具在之后写入 >提交已经发生,从提交中提取信息。例如,Git中的重命名检测是通过将所有删除的文件与所有新文件进行比较并比较配对相似性度量标准来完成的。如果相似性度量值大于 x ,则认为它们被重命名,如果它在 y 和<$ c $之间c> x ( y ),它被认为是重命名+编辑,并且如果它低于 y ,它们被认为是独立的。很酷的是,作为一个提交考古学家,你可以在事实之后指定什么 x y 应该。如果提交只是记录此文件是该文件的重命名,则这不起作用。



检测移动内容的工作方式类似:将每个文件分片,计算相似度所有切片之间的度量标准,然后可以推断出这个切片已经在这里被删除,而这个添加在那里的非常类似的切片实际上是从这里移动到那里的同一片。



然而,正如tonfa在他的回答中提到的那样,这非常昂贵,所以通常不会这样做。但它可以完成,这就是要点。



顺便说一句:这与Google使用的Operational Transformation模型完全相反Wave,EtherPad,Gobby,SubEthaEdit,ACE和Co。

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).

How does this work?

解决方案

It doesn't track them. That's the beauty of it.

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.

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.

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.

BTW: this is pretty much the exact opposite of the Operational Transformation model used by Google Wave, EtherPad, Gobby, SubEthaEdit, ACE and Co.

这篇关于git如何跟踪文件之间的源代码?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆