试试这个:
$ git diff --name-status -M HEAD^ HEAD
你应该看到的是,两次提交之间,这个文件被改名,并有一个 “相似性指数”(说)95:
R095 hash.c hashdic.c
(我根据你的发帖输入了这一行 - 一行呼叫.h
,其他人称之为.c
,我在这里用.c
去了;无论如何,它不会被剪切粘贴,所以可能会有一些小毛病 - 我弥补了相似指数值。但是,输出应该足够类似以识别,无论如何,我指望相似指数低于100%。显然至少有50%,因为这是默认设置。)
这表明在之前和当前的提交之间,文件被重命名和修改了一下。
一旦你做到了这一点,试试这个:
$ git diff --name-status -M100% HEAD^ HEAD
这个时候,你应该看到,hash.c
已被删除,hashdic.c
加入:
D hash.c
A hashdic.c
这表明之间的变化先前和当前提交已有否重命名,只有已删除的文件和已添加的文件。
这是什么?这是两个:这是一个地板蜡和一个甜点顶部!事实上,git动态地计算提交(或提交和索引或工作目录,或任何这样的配对)之间的变化,每次你要求它,你是运行一个明确的git diff
,还是运行git status
(或者运行git status
git commit
为你运行)。您可以指定是否允许重命名检测(--no-renames
),如果是,则指定相似度阈值(-M
)。
您也可以要求复印检测(-C
和--find-copies-harder
)。有多少“树名”可以应用这个限制,因为从计算的角度讲,可以通过比较每个文件中的每个文件和另一个文件中的每个文件来计算非常昂贵的代价。默认情况下,git限制你重命名检测,这比git更容易一些,因为git只对“在开始提交但不在目标中的文件名,vs在目标提交但不在开始的文件名”。除非你删除和/或添加额外的路径,所以git只需要将这两个文件相互区分,而不是针对任何其他文件,以获得单个相似索引和比较,为-M
设置)
大部分控制旋钮仅提供git diff
:git status
硬连线重命名检测到“开”和50%,例如。放入重命名检测队列的文件名的数量由git config
设置控制,diff.renameLimit
。其他的git命令,如git blame
,可以通过用户可设置的控件运行git的内部diff引擎,但并不是所有这些命令都与git diff
中的含义相同。例如,git blame
只查看一个文件,而不查看整个目录,因此它的-C
和-M
完全不同。