的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”
感谢 波阿斯
你在你的问题包括图像具有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
开头,后面会出现。
所以@torek,万一比几冲突,开发人员应该分析和检测这些冲突的三倍,并了解它是重命名/重命名?有没有一种方法可以缓解这种分析? –
如果您保存'git merge'命令的'CONFLICT ...'错误消息输出,您将获得必要的信息。在我看来,Git真的*应该*写这个索引,使其可以检索自动化和更好的'Git状态'输出,因为有不同种类的我称之为“高级别”合并冲突,难以区分没有这些数据。 (请参阅https://*.com/a/44360581/1256452) – torek
如果它不检测重命名,则不会触发冲突。但由于git知道发生了两次重命名,显然彼此冲突,所以会产生冲突。你为什么认为这两个重命名不冲突?他们用两种不可能的方式来处理同一个文件。这是一个冲突。 –
@Nils_M我明白我的错误,感谢托雷克答案,我只是仍然无法在众多的冲突时了解一个人如何可以分析和理解,这是重命名/重命名 –