关于git mv的行为以及如何跨名称边界检索文件历史，这个网站上有很多问题。我知道Git实际上并不记录文件的移动/重命名，但我并不完全理解手动操作的问题所在。
假设我想重命名一个文件，我关心的是保持它的历史。如果我的工作流程是这样的
git mv file.txt new_file.txt
<make substantial changes to new_file.txt>
git add new_file.txt
git commit -m "rename and change"
然后历史将被打破。 git log --follow -- new_file.txt的输出将是最近的“重命名和更改”提交。
但是，如果我改为使用类似的工作流程
git mv file.txt new_file.txt
git commit -m "rename"
<make substantial changes to new_file.txt>
git add new_file.txt
git commit -m "change"
那么好像我已经避免了休息。同一个日志命令的输出现在给我“更改”，“重命名”，以及之前file.txt所涉及的任何提交。
我意识到如果文件没有被大量编辑，这是多余的，因为在这种情况下Git会自行推断重命名。但就实际讨厌的问题而言，我能想到的最有可能的是某种合并冲突，而且我无法找到比常规方式更糟糕的情况。
我的问题是：我错过了什么吗？在这样做明确的“重命名”提交时，是否存在潜伏在某处的危险？
这样做没有任何事情变得更糟。目前，任何事情都没有变得更好，但是如果我能够解决它，并且如果我对Git的更改被接受，这可能实际上使git merge在某些情况下（可能在git merge中有一个标志参数）更好地工作。有一天，也许吧。
（具体来说，git merge目前只针对两个提示中的每个提示执行git diff <base> <tip>，而不查看它们之间的任何提交。在我看来，如果它为重命名文件的提交运行快速祖先路径扫描可能会很好，并且将所有这些重命名组合起来用于最终的基本到尖端差异。为了使这个扫描速度可接受，它需要只检查精确重命名，而不是近似重命名;所以添加一个提交重命名但没有其他的提交将启用这个额外的合并传递，如果它被添加，则在更大的代码更改中找到重命名。）
（由于在Git无法检测到重命名的大间隙中进行重命名，所以这会增加很多（如果有的话），这并不是很清楚，因为完成合并可能没有任何价值。）