的Git，在两个分支重新命名时，不会被检测为重命名

许多问题，其中问的Git未检测含量的变化后重新命名。我有一个不同的问题：在共同的祖先有文件f_rename.txt。在一个分支（发散）重新命名（只，而不是内容的变化），以f_rename_1.txt 在其他分支仅重命名为f_rename_2.txt的Git，在两个分支重新命名时，不会被检测为重命名

当合并两个分支，我得到的冲突：

我无法理解这种行为，即使我认为Git不会检测重命名操作，并假定f_rename_1是一个新的文件，那么为什么它标志着冲突？与什么冲突？

望着阶段的文件，很显然，这里没有修改过的文件（同SHA1）：我期待重新命名

/重命名为Git conflict (rename/rename)

我不问如何解决冲突！，但为什么Git的行为如此。我使用Git“2.13.3.windows.1”

感谢波阿斯

来源

2017-10-18 Boaz Nahum

如果它不检测重命名，则不会触发冲突。但由于git知道发生了两次重命名，显然彼此冲突，所以会产生冲突。你为什么认为这两个重命名不冲突？他们用两种不可能的方式来处理同一个文件。这是一个冲突。 –

@Nils_M我明白我的错误，感谢托雷克答案，我只是仍然无法在众多的冲突时了解一个人如何可以分析和理解，这是重命名/重命名 –

你在你的问题包括图像具有git status输出。

的CONFLICT (rename/rename):你期望由git merge命令打印。

该跟踪，这留在索引，你现在看到的是，该索引有一个阶段1条目的原始名称（没有阶段2或阶段3条目），一个（没有阶段1或阶段3条目）的一个阶段2条目，以及另一个新名称（没有阶段1或阶段2条目）的一个阶段3条目。 git status命令将打印该类型跟踪的输出。

看看您的linked question的接受答案，它显示相同的git status输出。 both deleted行只是稍后，因为输出按文件名排序，而will-be-deleted以w开头，后面会出现。

来源

2017-10-18 18:20:38 torek

所以@torek，万一比几冲突，开发人员应该分析和检测这些冲突的三倍，并了解它是重命名/重命名？有没有一种方法可以缓解这种分析？ –

如果您保存'git merge'命令的'CONFLICT ...'错误消息输出，您将获得必要的信息。在我看来，Git真的*应该*写这个索引，使其可以检索自动化和更好的'Git状态'输出，因为有不同种类的我称之为“高级别”合并冲突，难以区分没有这些数据。（请参阅https://stackoverflow.com/a/44360581/1256452） – torek

的Git，在两个分支重新命名时，不会被检测为重命名

回答

相关问题