git - Git 如何知道我重命名了一个文件，而我并没有这样做，而是有意为之？

Question

事实上我没有重命名它，我用 linux rm 删除了 hash.c，然后复制了一个更新版本的哈希表实现，名为 hashdic。 c 和来自另一个目录的 linux cp。删除的文件和新文件非常相似，但不一样，因为我在另一个目录中处理了几个小时的 hashdic.c。

然后我输入了git rm hash.c(虽然它已经从文件系统中删除，也从存储库中删除)，然后输入git add hashdic.c.

然后 git commit -am "update to hash table"。还有魔法! Git 说:

renamed:    hash.h -> hashdic.h

但是，福尔摩斯，怎么办？如果从技术上讲我只是删除了文件并在 DIFFERENT 名称下添加了一个新文件，git 如何知道我实际上重命名了该文件？

---

整个过程:

• 从 ~/project/hash.c 复制/粘贴到 ~/other/project/hashdic.c
• 编辑~/other/project/hashdic.c
• rm hash.c
• cp ~/other/project/hashdic.c ~/project/hashdic.c
• git rm hash.c
• git commit -am descr

Answer 1

试试这个:

$ 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 diff，git 都会在您每次请求时动态计算提交(或提交和索引或工作目录，或任何此类配对)之间的更改，或者您运行 git status(或 git commit 为您运行)。您可以指定是否允许重命名检测 (--no-renames¹)，如果允许，相似度阈值是多少 (-M ).

您还可以要求复制检测(-C 和--find-copies-harder)。将此应用到多少“树名”有一些限制，因为从计算上讲，将一次提交中的每个文件与另一次提交中的每个文件进行比较可能会变得非常昂贵。默认情况下，git 限制你重命名检测，这更容易一些，因为 git 只对“在开始提交但不在目标中的文件名，与在目标提交中但不在开始中的文件名”这样做".

(在这种情况下，分别是 hash.c 和 hashdic.c，除非你删除和/或添加了额外的路径。所以 git 只需要区分这两个文件相互比较，而不是针对任何其他文件，以获得单个相似性索引并将其与 -M 设置进行比较。)

---

¹大多数这些控制旋钮仅在 git diff 中可用:git status 硬线将检测重命名为“on”和 50%，例如。放入重命名检测队列的文件名数量由 git config 设置 diff.renameLimit 控制。其他 git 命令，例如 git blame，使用用户可设置的控件运行 git 的内部差异引擎，但并非所有命令都与 git diff 中的含义相同。例如，git blame 只查看一个文件，而不是整个目录，因此它的 -C 和 -M 是完全不同的。