本网站上有很多关于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的输出将是最新的＆＃34;重命名和更改＆＃34;提交。
但是，如果我改为使用像
这样的工作流程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会在这种情况下自行推断重命名。但就实际讨厌的问题而言，我能想到的最可能的是某种合并冲突，而且我还没能找到比常规方式更糟糕的情况。
我的问题是：我错过了什么吗？是否有潜在的危险隐藏在一个明确的＆＃34;重命名＆＃34;像这样承诺？
答案 0 :(得分：0)
通过这样做，没有任何事情变得更糟。目前，任何更好的都没有，但如果我能够解决它，并且如果我对Git的更改被接受，这实际上可能会使git merge在某些情况下更好地工作（也许将来会有git merge的旗帜参数。有一天，也许。
（具体来说，git merge目前只为这两个提示中的每一个提供git diff <base> <tip>，而不查看它们之间的任何提交。在我看来，如果它快速运行可能会很好用于重命名文件的提交的祖先路径扫描，并为最终的基本到尖端差异组合所有这些重命名。为了使此扫描速度可接受，它需要仅检查精确重命名，而不是近似重命名;因此添加提交如果它被添加，那么重命名 - 但没有 - 其他会启用这个额外的合并传递，以在更大的代码更改中找到重命名。）
（这并不是很清楚，因为在Git无法检测重命名的大间隙中重命名，这会增加很多，如果有的话，可能没有任何价值来完成合并。）