Git mv命令和更改以及相似度指数

Question

当使用git mv重命名文件时，提交记录将显示重命名前和重命名后的名称，在拉取请求中也会显示相同，这很好。但是当文件被 git mv 更改后，似乎有一个特定的阈值，超过此阈值的更改行数，则不再显示为重命名，而是显示为旧文件已删除并添加了新文件。所以我的问题是，这个阈值是否有明确定义的数字？还有其他方法可以使其更好吗？主要因为在拉取请求diff中，当两个文件不被视为重命名时，diff不会并排显示，这使得审核变得困难。

- fluter

Answer 1

它基于差异相似度指数。

如果指定了n，则它是相似度指数的阈值（即相对于文件大小的添加/删除量）。

例如，-M90％表示Git应该认为删除/添加对是重命名，如果文件未更改的部分超过90％。

没有%符号，数字将被视为分数，并在其前面加上小数点。即，-M5变成0.5，因此与-M50％相同。同样，-M05与-M5％相同。

要限制检测到精确重命名，请使用-M100％。

默认相似度指数为50％。

更一般地说，最好先将文件mv/rename，提交，然后进行一些修改。
如果所做的修改与文件的其余部分相比较小（典型情况：重构，仅更改包的名称），则可以同时执行这两个操作。

- VonC

---

是的，在一个提交中进行mv操作，然后在另一个提交中进行更改似乎是个不错的选择。谢谢。 - fluter

在拉取请求工作流期间，即使进行了初始的git mv提交，然后是修改提交，是否仍有可能破坏移动检测？基本上，如果始终先执行git mv，然后再进行修改提交，则文件重命名将始终被正确地捕获，无论对该文件进行了多少次修改。这准确吗？ - jxramos

@jxramos 我相信是这样的。将mv与修改分开更安全（但很少有人想到以这种方式拆分他们的更改）。 - VonC